Package license considerations

[ktchu]

What do you all think about considering Apache 2.0 as the license for the package? A couple of years ago, I reviewed several of the most common open-source licenses and came to the conclusion that Apache 2.0 provided a nice balance between the trade-offs between

• restrictions on use (minimal),

• avoiding infection of derivative works (minimal),

• readability (longer than MIT and BSD but not too long), and

• protection against hostile intellectual property claims (e.g., somebody adding code and then filing a lawsuit claiming patent infringement).

The inclusion of the last feature (without sacrificing too much on the first three) is the main reason that I use this license for all of my personal open-source projects.

Thoughts?

[serenity4]

I personally try to stay away from dealing with patenting, and have little experience in the matter. I would suggest to:

• Leave the MIT license (or a similar license that heavily emphasizes the first three points) for this package.
• Have implementations use more restrictive/protective licenses at their will.
• Reconsider the matter when we actually implement anything with a high-value into this package.

On the long term, I would think that if the package is well adopted by the community, we should not have much to worry about people "stealing" our work. For example, some packages provide very high value, with MIT licenses, are widely used and never had any issues. Please let me know if I'm wrong about that, and if you encountered particular problems yourself; as I mentioned, I don't have much experience there.

[ktchu]

@serenity4, your suggestions sounds reasonable and I am fine with. I agree that there are many high value packages with MIT licenses that don't have any problems. My hope is that would be the case for our packages as well. My time in industry has suggested that it doesn't always work out that way, but I think we can certainly wait a bit before changing the licensing.

For clarification, my understanding of the Apache License is not that it prevents theft of work. Rather, it is protect the contributors to the package. Examples of protections granted to the contributors:

• makes explicit that by default the intellectual property of any contributions are effectively transferred to the package and must be licensed under the same license as the rest of the package;

• includes a deterrent against claims that the package is infringing on software owned by another entity (by revoking patent licenses to any entities that file patent claims against the package contributors).

[ktchu]

@serenity4 @eschnett @wgvozdjak. A quick follow-up question for everybody. Does anybody have any work agreements (e.g., working at a university on a project directly related to geometric algebra funded by grants through the university) that could potentially impact our ability to open-source license your contributions?

As a concrete example of the situation with work funded under university grants, I co-authored a software package during my postdoc that was related to my research work. The situation was the same for my co-author. As a result, the software cannot be released under a pure open-source license (even 15 years after the original software was released). Instead, we use a hybrid license that permits open-source usage for "personal use" and direct inquiries for commercial use to the university technology transfer offices (though we are currently working on a simpler licensing option for commercial entities). Even packages like FFTW don't have a pure open-source license (though their situation would be different from ours because the open-source part of their license is copyleft which has stricter requirements for inclusion).

Regarding Velexi Corporation, I am the owner and CEO of the company, so I will create an internal document (with executive signature) to make it clear that GeometricAlgebra.jl is to be licensed under an open-source license and that the company retains no claims on the software (into perpetuity). From a practical perspective, this technically isn't necessary because I own and run the company. However, as I learned from my corporate lawyer, putting the documentation in place reduce confusion if Velexi were somehow taken over by another entity. As a concrete example, consider the situation of Oracle purchasing Sun Microsystems and becoming the owner of the (proprietary version of the) Java codebase.

[serenity4]

Thanks for the clarifications. There is no issue about open-sourcing contributions for me, as I contribute in my free time as my own person, with no affiliation to any entity.