Yzena Access License Frequently Asked Questions

  1. What is the Yzena Access License (YAL)?

    It is a network/public-use copyleft license that is more permissive than the GNU AGPL.

  2. Is the YAL viral like the GNU GPL and the GNU AGPL?

    No, it’s explicitly not viral. In my opinion, virality has caused people to use closed-source software instead of FOSS alternatives when those alternatives were licensed under the GPL and AGPL, so the YAL is not viral to give developers the option to avoid it, should they wish.

  3. Who are you? And are you a lawyer?

    I am Gavin D. Howard, founder of Yzena.

    No, I am not a lawyer, but most of this license is taken from the Blue Oak Model License 1.0.0 (BOML), which was written by lawyers.

  4. Why did you choose the BOML to start with?

    See here, here, here, and here. Basically, the BOML is supposed to be a model for how licenses should be.

  5. What is the list of changes you made from the BOML?

    These are the changes I made:

  6. If you mostly copied the BOML, why shouldn’t I just use that one?

    You actually should; if all you need is a typical permissive license, then yes, you should use the BOML.

    However, there are five important clauses in the YAL that are not in the BOML:

    If you need those three things in a license, then the YAL might work for you. Be sure to consult with your lawyer first.

    In addition, this is also a network/public-use copyleft license, so if that’s what you need, that is another reason the YAL might work better for you. Again, be sure to consult with your lawyer first.

  7. Why Did You Name Your Network License the Yzena Access License Instead of the Yzena Network License or the Yzena Public License?

    Yzena Network License was its original name, in fact, but I changed it for two reasons.

    First, the YAL applies to all public use, not just network access. I thought about naming it the Yzena Use License, but that name does not imply public use. Access is not perfect either, but it’s better.

    I also did not use Yzena Public License because its abbreviation would have been YPL, and that is already taken by the Yahoo! Public License.

  8. Why do you use such vague language and don’t define some of your terms?

    Because the BOML doesn’t. See more here and here. I decided that if lawyers did it, it should be fine.

  9. Why did you specifically say that the license is a contract?

    To avoid the problem described in Kyle E. Mitchell’s post “We Were Wrong About the GPLs,” which talks about why FOSS licenses should be contracts.

  10. Your definition of combined software is too vague. “One piece of software” can mean anything.

    This is intentional.

    The linking definition of the GPL and friends is too specific. On the other hand, the broad definition of the SSPL might be unenforceable.

    This definition, that the software has to be “one piece of software” is a compromise; it is broad enough to cover cases where software is not “linked” per se, but it is also narrow enough to pass muster in courts (I hope).

    This does mean that contributors and recipients would need to convince courts that a given piece of software is one piece of software in the beginning of all litigation about the YAL, but I am okay with that.

    And for the avoidance of doubt, my personal definition of “one piece of software” is software that, when combined, executes in the same address space and in the same way.

    This definition includes linking in a library (it executes in the same address space, and a linked library will also execute in the same way: directly with machine code).

    This definition does not include an interpreter running a piece of software. While they technically share the same address space, they are not executing in the same way. (The interpreter is running on the machine, the program it is running is running on the interpreter, not the machine.)

    Another example of things that would fall under this definition are Linux kernel modules with the kernel itself; they are in the same address space (Ring 0), and they all directly execute on the machine. (Yes, this does mean that Linus is within his rights to shun OpenZFS, unfortunately.)

    This would not include EBPF programs, which are run by an interpreter in the kernel.

    It also does not mean the kernel is the same piece of software as software running in userland because they execute in different address spaces.

  11. Your Credits section doesn’t actually require giving credit.

    No, it doesn’t. But it does require providing the verbatim text of the CREDITS.md, NOTICE.md, other similarly-named file, and I assumed that the contributors would add whatever credits they wanted in there.

  12. You also don’t require giving a link to the original project, if someone makes changes and relicenses the code.

    No, but I also assumed that the original contributors would put that information in the CREDITS.md, NOTICE.md, or other similarly-named file, and that text must be provided verbatim.

    That assumption simplified the license, which makes things easier on contributors and users.

  13. The Credits section says that it is required to provide the verbatim text of the CREDITS.md, NOTICE.md, or similarly-named file. Why didn’t you just require people to provide the file?

    Because if someone makes changes to the software, I wanted them to be able to add their own credits to the file, which they can do by adding theirs at the bottom or the top of the original, since the verbatim text of the original will still be intact.

  14. What do you suggest putting in the CREDITS.md or NOTICE.md file?

    I suggest adding these things:

    • The name of the original software.
    • The original copyrights on the software.
    • A link to the original code/repository.
    • A link to the Yzena Access License to inform users that it is possible to get the original under this license if they wish.
    • The (preferred) names of all contributors that want credit.

    I also suggest having a paragraph that says:

    All files in this repository are under the Yzena Access License, Version 0.1, and all such files are considered part of the “source code” as defined by that license.

    In addition, if there are files in the repository that used to be under any licenses other than the YAL, then I suggest listing all such files, along with their respective former licenses and copyrights, as required by their former licenses, but to also make clear that the files have been relicensed.

  15. The previous question implies that everything in a repository should be under the YAL. What if there is code that is under other licenses?

    Such code should be relicensed, if possible. This is possible with permissive licenses.

    If it is not possible, then such code should not be integrated into the repository.

  16. Does this mean that any code under the GPL family of licenses should not be integrated into a repository under the YAL?

    Yes.

  17. Why do you care about patents and trademarks?

    Because I want to be able to make a business based on Open Source software, and I do not want to have to worry about losing trademarks or possibly getting sued for patent infringement.

    Also, software patents are, in my opinion, illegal because you can’t patent algorithms. They have also never been used for actual innovation, which makes them useless.

  18. Why did you not use a sunset clause, like copyleft-next? That seems like a good idea.

    It is a good idea, since the term of copyright is much longer than it should be.

    However, unlike movies or other works of art, software is constantly changing. So if there was such a sunset clause in YAL, it might be ambiguous whether or not the clause applies to all of the software, or just those portions that have existed as long as the sunset term.

    Instead, I opted to keep the BOML’s Reliability clause, which should serve the same purpose.

  19. Why did you not use a nullification of copyright clause, like copyleft-next, to prevent proprietary dual licensing?

    While that clause is also a good idea, its purpose is also somewhat fulfilled by the Reliability clause.

  20. Why did you use the vague phrase “make…this software…part of any application that is available for public use”?

    I intentionally wanted to make the requirement for sharing source kick in for every public use of the YAL-licensed software, whether direct or indirect. I want code to be shared, first and foremost.

    Obviously, if a company makes a public-facing webapp that uses YAL-licensed software, that is making it available for public use, and they should be expected to share their changes, if any.

    However, if YAL-licensed software is used only as part of private infrastructure, there is no expectation to share changes.

    Also, this definition has some other good side effects: it includes software used on things like arcade machines and software included on OEM machines as well, among other things.

    Yes, if YAL-licensed software is used in an arcade machine available in a public arcade, that is covered under this definition, as is any software that comes preinstalled on computers or phones sold by manufacturers.

    In essence, the reason is that this is a tiny change from the “available to the public” phrase used in the GPL (which already covers software distributed with devices) that should cover the SaaS loophole.

  21. Where do you draw the line “part of an application available for public use”?

    My line is best illustrated with an example.

    Say I write database software and license it under the YAL. If a company makes a publically available webapp that stores data in my database, even if that database also holds data for their non-public monitoring system, I would consider that the database is part of the publically available webapp, and they should share changes.

    However, if the company does not use my database to store data for the webapp, but only uses it to store data for their non-public monitoring systems, then that would not be part of the publically available webapp, and they do not need to share changes.

  22. What’s with the weird definition for “this software”?

    GitHub Copilot. I want the YAL to poison the well for machine learning like that.

    The reason is that GitHub is arguing that using FOSS code in Copilot is fair use because using data for training a machine learning algorithm has been labelled as fair use.

    However, even though the training is supposedly fair use, that doesn’t mean that the distribution of the output of such algorithms is fair use.

    The definition of “this software” is crafted to exploit this discrepancy.

  23. But maybe the output of the algorithm is under fair use as well.

    If it is, then copyright disappears entirely from software. The reason for this is that we already use algorithms to transform our software. We call those algorithms “compilers,” and their output “executables” or “libraries.” No one claims that a source code’s copyright does not apply to the binary forms output by a compiler.

  24. What if the output of a machine learning algorithm is transformative? Would that not be enough to defeat copyright?

    A compiler’s output is also transformative, especially if it does optimizations. This especially applies if the compiler is doing link-time optimization using inlining with code from different sources. In that situation, a compiler is combining multiple sources in non-obvious ways, just as machine learning models do.

    A compiler can even transform an O(n) algorithm into an O(1) algorithm!

    In other words, unless GitHub Copilot wants to throw out copyright on software completely, this license will apply to the output of its model.

  25. Why didn’t you just add a clause protecting the output of machine learning?

    I think the definition is wonderfully broad in a way that is best for end users, which is my central purpose: to serve end users who are hurt most by proprietary software.

    In addition, I don’t know what sorts of things will be done to software in the future, and I want to future-proof this license as much as possible.

  26. Your extra restrictions make your license incompatible with the GPL and AGPL.

    I don’t think so.

    First, they are not extra restrictions; they codify something that I believe already exists in the GPL and friends.

    Second, even if they are extra restrictions (which would make this license incompatible with the GPL), I think I am okay with that.

    In fact, if my licenses are not compatible with the GPL and friends, then I will keep the terms I have and accept the incompatibility. I can do this because these licenses will mostly be used for code in a new language, which means that I wouldn’t be able to use existing code easily anyway.

  27. Your extra restrictions make your license non-Open Source.

    Once again, I don’t think so, and for why, see above. The new parts are not new restrictions; they are clarified.

    But even if the license is non-Open Source, I’m not sure I care.

    The reason is this: I believe FOSS licenses have failed. We have so many companies that have used the freedoms we have tried to give users in order to extract value (data or something else) unethically from those very users. They do this by claiming the rights of distribution that the FOSS licenses give them and then using those rights to distribute Open Source software to users in such a way that they don’t realize that they are being taken advantage of.

    The more I’ve understood that, the more I have come to realize that the current iteration of FOSS licenses do not work.

  28. But what will work?

    Remember how I said that companies claim the rights of distribution we give them? As it turns out, end users, so-called because they are at the end of a chain of distribution, don’t usually use distribution rights.

    That means that the next generation of FOSS licenses can probably more heavily restrict how licensed software is distributed while allowing for no restrictions on the other two freedoms of the four freedoms.

    I’m not ready to go that far yet. If I was, I’d add a clause forbidding ads in the software. But that is probably the sort of direction we need to go.

  29. Your license is actually viral, since it makes the license apply to the full output of algorithms.

    I carefully defined “source code” to ensure that was not the case.

    You see, while the license does apply to the entire output, the requirement is still to provide only the source code of the original. There is no requirement to provide the source code of the entire combined software.

  30. Why did you say that “this software” only includes output of algorithms that is itself software?

    Technically, you can run software through things like hash functions, which are algorithms, and the output is entirely unusable as software. Saying that the license would apply to output like that would never work.

    The same goes for static analysis tools. They don’t usually output something that can be considered “software”; instead, they output a list of problems with the software. I wouldn’t want that to be affected by this license.

    In other words, that little part of the definition is required from making the definition so broad that it becomes useless, or worse, unenforceable.

  31. Your definition of “this software” has “this software” in the definition.

    That’s because the definition is recursive. The base case is the source code of the software, and then whenever the source code, or the result of transforming “this software” is transformed by an algorithm, the definition recursively applies.

  32. Why did you define “source code”?

    In order to make this license non-viral and because of the recursive definition of “this software”. See the previous question.

  33. What’s up with the Non-Interference clause?

    That’s the anti-Tivoization clause.

  34. Your Non-Interference clause is too much of a burden.

    I agree that it can be, and like Linus Torvalds, I think there can be legitimate uses for Tivoization.

    Therefore, I also explicitly recognize the use of the YAL without the Non-Interference clause.

    If you do use this license that way, then to prevent confusion, please call it the “Yzena Access License 0.1 with the Non-Interference Exception” or “YALNE 0.1”.

  35. **Your Non-Interference clause will let companies get away with just providing the source code, and they will take advantage of that to make it impossible to modify products and use the modified versions.

    That’s why there is a tiny phrase, “and make it possible,” in the clause.

    This tiny phrase is what will require companies to disclose the materials, tools, and/or information required to modify the software, build the modified software, and incorporate it into the product.

  36. Why did you include an indemnity clause?

    This was suggested by an open source developer facing a lawsuit. That developer said that perhaps if the license used had had an indemnification clause, the lawsuit might not have moved forward.

    I don’t know how true that is, but I figured I would put the clause in unless a lawyer says otherwise.

  37. Why is there a clause saying that the disclaimer needs to be legal?

    Because apparently, the UK might not recognize such disclaimers, and neither might the EU if the Cybersecurity Resilience Act passes.

    I don’t want to open myself up to litigation for trying to do the right thing.

  38. Why is there a sentence saying that contributors have no duty towards users?

    For the same reason as the above question. This second sentence should clarify that contributors have no duty, including fiduciary duty, towards users, and if they do, there is no license, which, in either case, means that there is no duty.

    Yes, this means that in Britain, this license may be null and void because of a lawsuit. I personally believe that it will be null and void in the EU if the Cybersecurity Resilience Act is passed.

  39. Why does the license explicitly say there’s no relationship between users and contributors?

    It was suggested by an open source developer facing a lawsuit.

  40. Why did you write this FAQ when nobody has asked you any questions yet?

    To establish intent. If these licenses have to be tested in court, then if my intent is clear, that can help judges and juries resolve ambiguities and decide if a license violation happened.

    The GPL and AGPL did the same thing. However, in those cases, the licenses include the intent in the preambles to the licenses, which muddies the waters. The reason for this is because if the preamble conflicts with another part of the license, which part wins?

    To stop that from happening, I set forth my intent in this FAQ, but I also explicitly made it a separate document (in the repository). That way, if the FAQ conflicts with the license, the license wins hands down.