The Apache license is long and needlessly complex

Archive General
1

The Apache license has cumbersome requirements such as the requirement to “cause any modified files to carry prominent notices stating that You changed the files”

How would you feel about changing the licenses of sifive projects to the MIT license?

If you are concerned about patents there are a few options.

  • You could add a separate file to grant a patent license similar to what go does.

  • Switch to the COIL license instead, which includes a patent waver, but is much simpler and more free then Apache.

  • Dual license, include both the MIT license and the Apache license, and allow the user to choose which license he accepts.

1 Like
2

There are at 4 key considerations we’ve used to conclude on Apache 2.0.

  1. Needs to be permissive
  2. Needs to include patent grants (e.g. MIT doesn’t)
  3. On the approved list published by the Open Source Initiative https://opensource.org/licenses (e.g. COIL is not on this list)
  4. Needs to be widely accepted by commercial entities in the ecosystem. On this last point, Apache is well understood and accepted by many large companies’ legal teams.
3

The requirement for a notice in each changed file is a bit of a pain, but very easy to automate, for example by a git/svn check-in hook. Just check if your line is already in the file, and if not then add it.

4

I understand your concern about COIL.
What do you think about the other two things I suggested?
I think both of them fit all four of those criteria.

1 Like
5

Thanks for the suggestion.
But in general I prefer to not have to deal with that and impose that extra work on people who might want to contribute to my own projects.

The terms of a copyright license carry an implicit threat of a large lawsuit.
I would love to be able to trust developers to be reasonable, but the purpose of free software licenses is to dissuade these concerns.
Whether it is the intention of the original developers or not, anyone who wants to create a derivative is not merely being asked to follow the license, he is being forced.
For that reason I think even a minor unnecessary hassle such as the bookkeeping clause should exclude licenses from being considered free.

1 Like
6

That’s a good point for dealing with these hassles if I’m ever forced (by circumstance or employers) to work on an Apache licensed project, so thanks for mentioning it. For the most part, though, I prefer to avoid contributing to projects where a momentary lapse or scripting bug could expose me to the risks of litigation, and to avoid incorporating anything into my own projects that would require other people to shoulder those risks (and the burden of using commit hook scripts to help insulate them against legal risk). As such, it’s not really a very broadly applicable solution.

7

This particular clause only applies when redistributing the original work or derived works, not contributions to the original project.

For example: If you made a contribution to the Apache server source you wouldn’t need to add a notice for every submission. If you forked the Apache server source, added FEATURE-X, and subsequently released the shiny new Apache-X project to the world then you’d need to apply the notices where applicable on source which was taken from the Apache codebase that’d you’d made alterations to.

I appreciate this is a bit subjective, but is it really that bad? It fits on about two sides of paper and clocks in ~1600 words. By comparison, the GPLv3 is >5600 words. Granted, the MIT is a tiddler compared to both …

8

If I work on a project that grew out of a fork of another project, though . . . and, of course, though most people ignore this fact, forking on GitHub to make changes and submit a PR back to the original project surely constitutes distributing changes independently in the eyes of the law (unless you have a paid account and make the fork private).

I have similar concerns to passstab’s about the complexity of AL2, not necessarily because of the bytecount (that’s trivial even for the GPL for many projects), but because of the legal complexity that arises. One of the dangers of complex licensing documents is the conditions that might arise from interactions between different parts of a license, just as cyclomatic complexity in a piece of software gives rise to increasing numbers of bugs. In fact, “bugs” is a great term for the kinds of difficult-to-discern subtle gotchas that arise in longer software licenses.

1 Like
9

Yet you’re OK with using code that does not have a patent grant on contributions, where any code you use could expose you to an IP lawsuit from the original contributor?

As Jack mentioned, we use Apache because it is well established and helps resolve a big problem with the original BSD license when accepting code from others. Every legal document is logically incomplete and full of bugs, so people put faith in licenses / contribution models that have been reviewed by many legal departments, used in practice for a while, and otherwise tested.

10

Patent law does not work the same way as copyright law, so the benefits of a patent clause are dubious. Sure, the patent clause means one person won’t sue me for patent infringement or demand licensing fees – at least for the patents that person holds at the time he or she makes those contributions (though patent clauses typically say nothing about patents registered later or currently pending, or about other contributions added by other people later, all of which can be gamed by a sufficiently malicious person) – but it provides no protection against patents potentially owned by seven billion other people on the planet. Copyright licenses, however, “just work”; with a good license you have no fear of being sued, as long as you observe the license restrictions.

Dual-licensing should solve all these problems, anyway. It means that people who contribute grant a patent license, but for those who need to be able to use your code without significant administrative overhead in license observance, and for those who want to combine your code with other open source licensed code (e.g. GPLv2, which is incompatible with AL2), there is a licensing option that does not screw them over. Is there some reason you object to dual-licensing with the MIT License or Simplified BSD License?

1 Like
11

The problem with dual license is that (obviously) not all contributors would want to contribute under both licenses, so how do we manage redistribution of their contributions without fragmenting the code base? If you’re just using the code, as opposed to contributing, there is really no overhead versus BSD. I think you’re overestimating both the adminstrative overhead of complying (as others have noted) and the likelihood someone will sue you for a benign fork of the code if you don’t, and are also underestimating the nervousness that many have in the hardware space about using code without even the admittedly minimal protection of a contributor patent grant. Our belief is that in the open-hardware space, AL2 will lead to our code base being more widely used and contributed to than with other license regimes.

12

My guess would be that your choices are as follows:

  1. Use two licenses (dual-license). Gain those who like one license and are willing to dual-license, and those who like the other license and are willing to dual-license. Possibly lose those who refuse to license under one or the other, though I have no real idea why that would happen with AL2 and MIT License, except maybe in the very fringe-y case of people who don’t want to deal with AL2 terms (but would be okay with the MIT License or some flavor of copyfree BSD License).

  2. Only use one license. Lose everyone who would only contribute under the other license, and everyone who would contribute under dual-license terms but prefer the other license, and those who want their code to be compatible with GPLv2, while you gain only those who prefer the license you kept. I’m not sure this is an improvement, even if there are more people who refuse to dual-license than seems likely (a very small if).

I don’t recall saying there was more overhead, but there is certainly more legal prohibition that would prevent other projects from using it. License incompatibility is a real problem.

  1. You can think I’m overestimating the overhead all you want, but the legal terms are right there, in the license. Read them.

  2. I don’t overestimate the likelihood of getting sued. I think it’s very small, if your errors in compliance are innocent errors. It’s probably as small as the likelihood I’d get run over by a car walking across the street in front of my home without looking both ways first – but I still look both ways before crossing, and find it foolhardy to not do so.

  3. I know there’s a lot of “nervousness” in hardware fields related to patents. Dual-licensing does nothing to make that any worse, relative to using AL2 alone.

Sure, that’s not an entirely unreasonable estimate of likelihoods, at least until the problems of license incompatibilities become a bigger concern (and that concern appears to be growing steadily, if slowly, over time). What boggles my mind is the resistance to broadening the appeal by dual-licensing.

13

Choice 1) is too complex to sell to a company, where many of the contributors will eventually be. It’s bad enough selling any open-source approach to a company, but making it complex makes it worse. We’re trying to make open-source silicon usable, and then standard, across the commercial space, otherwise it will remain a hobbyist backwater.
We’re picking choice 2) I guess I just don’t believe we’ll lose many people staying with just AL2, and having simpler model can attract contributors, especially from companies. GPL (either version) doesn’t work for silicon anyway (although I think a new copyleft-style license could be defined if someone had the energy to work on it).

The resistance is purely based on our estimate of return/effort, and the fact it could be negative, though I can see that reasonable people might disagree.

14

Before considering licenses for hardware, you should also be aware of the potential problems with license inclusion terms – an issue that escaped my memory until just now, and I hunted down a relevant article on the subject:

This is relevant to more than just BSD licenses. Ideally, one should use software-nonspecific licenses, and those that do not require inclusion of license terms with hardware (or “binary” or any other terms that might be interpreted as covering hardware in a court of law). Licenses like the Detachable Public License (which is also not written in a software-specific manner) are better-suited to hardware distributions than most software licenses.

I’m having a difficult time imagining how one would include NOTICE and license files with a CPU (for instance). Perhaps microdot printing on a label, though the “readable form” requirement in AL2 seems violated by that approach.

Keep all that in mind when managing license compliance in the future.

You’ve lost at least one. I know some other people who will probably come to the same conclusion. Luckily, there are other RISC-V competitors out there who use better licensing.

Good luck.

15

Ciao and good luck.

For the record, Apache is fine by me. At least it’s not @#$%^ GPL. I void putting any significant amount of work into GPL’d things, unless they are mere tools and won’t become part of a shipped project, because I like to be able to use the results of my own labour in my commercial work.

16

Thanks for this discussion. It is apropos to our decision of whether to join and contribute to the SiFive eco system. We are implementing a high performance low power RISC-V core and are considering adopting the SiFive U5 Coreplex as the basis for the chip infrastructure, versus using the Rocket Chip distribution directly. The heart of our product’s value rests in a pending patent that leads to its 60 to 1 advantage over Intel based servers. As such the following clause within the SiFive license, regarding patent rights, is a major concern:

" If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed."

Our reading of this is that it appears to introduce a form of copy-left mechanism, under the following scenario. We manufacture a device from a mixture of sources, one part being Chisel that you have released under Apache, and another part being our own Chisel, which we have not released publicly. Our Chisel code embodies our patents and has been developed clean-slate, and kept private. We synthesize a chip and sell a system that includes the chip.
We are concerned that the above clause may come into play regarding reverse engineering. For example, a competitor reverse engineers our chip, takes our portion, which was not released in any other form, and uses the reverse-engineered source code to manufacture their own chip. When we sue that competitor for relief, then it appears that there may be a possibility that we lose any patent rights granted through your portion of the source, due to the above clause. This may open us up to counter suits, claiming that because we are suing for relief due to infringement of our patents, and our chip as a whole used code released with the above clause, that now we are infringing patents owned by contributors to SiFive’s distribution.

The issue hinges on whether the sale of a chip derived from both sources satisfies the conditions for the above clause. Existing case law may not cover this area clearly. The issue is similar to reverse engineering of the compiled form of code, especially given that the license’s definition of “Object” form includes “mechanical transformation”, which may cover reducing the code to transistor form. The case can be made that the transistors on the chip are equivalent, legally, to the compiled form of code. As such, by selling a chip that contains this “Object” form of SiFive source code, we are de-facto distributing a derived work that carries the above clause.

Has SiFive legal council considered such an argument? If so, could you share the conclusions and any case law they have uncovered to address this?

Obviously, if the above argument holds, then no company can release a chip that contains patented portions, without either losing the right to enforce the patents or else opening themselves to being sued.

Thank you. And thank you for the work SiFive is doing. We hope to contribute back to the project.

Sean Halle
CEO Intensivate
http://intensivate.com

17

Apache does not have the effect you’re worried about. The Apache license terms only cover the code you contribute to the code base under the licence (“the Work”), and prevents you from suing others for the Work. We could not accept contributions from others without this clause. You can still sue if you believe a third party infringed patents in your non-contributed code, i.e. the non-Work.

18

Got it, nice. Thanks for the update.

Unfortunately, for us, since first posting this it has come to my attention that U5 Coreplex is not released under Apache, but rather under commercial license only, and that recipients do not have the right to modify it. That is probably good news, though, because it means SiFive has a defensible IP to generate income, which fuels the work on the portions that are open source. The one request that I would have is that there do not appear to be pages that talk about these sorts of legal aspects of the different SiFive code bases. It is a bit opaque figuring out the map of SiFive products and projects, and which are open source permissive and which are not. Thanks for doing SiFive and thank you for the projects that are released open source. I wish you success.

Sean
Intensivate

1 Like