How to Audit licensing of old project?

Question

I manage a project with a very long open source history - Zikula (and https://github.com/zikula/core).

Zikula grew out of PHPNuke and PostNuke. Most of the oldest code is long gone, but some legacy remains. Early documentation states "Zikula is free software released under the GPL license!". Most files within the project have a header which directs to a copy of the GPL or LGPL and there is a NOTICE which discusses the mixture of licenses within. Additionally, we depend heavily on Symfony which uses MIT and contributions since beginning on Github in March 2010 are tagged as MIT. We also have many vendors within the project of various licensing.

We have a ticket requesting some clarity on the licensing and I am unable to answer. First, because of the information above and second because of my lack of understanding.

I think I would prefer Zikula be licensed with a permissive license like MIT or LGPL (as I believe they are?). The GPL seems to be too restrictive for our case, but likely was the dominant option at the time (15 - 20 years ago?). From what I understand the GPL is "infections" and subjugates other licenses within the project.

How can I straighten out this spaghetti? I'm a coder, not a lawyer. How do I audit the current code base and know what was contributed under what licensing and how do I ensure compliance in the future? How to I mix these licenses together or change and relicense as MIT/LGPL or similar?

Answer 1

This is going to be long, because changing the license from the GPL to a more permissive license is really complicated for a project that is big, old, and has many contributors.

Which license

An open-source license should not be chosen because it is popular, but because it is aligned with your goals:

• Strong copyleft licenses like the GPL (and for web apps: the AGPL) try to maximize freedom for end users of any application using this code. This limits how other developers can use the code.

• Weaker copyleft licenses like the LGPL don't ensure end-user freedoms for the complete application, but only to those components subject to the license. This allows developers to incorporate such code into proprietary projects under certain conditions, but does not allow them to turn the code proprietary.

• Permissive licenses like the MIT license and Apache License 2.0 try to maximize freedoms for developers at the expense of end users. Developers can create and distribute modified versions without having to publish their source code. For new projects, the Apache License 2.0 should probably be strongly preferred since it includes a contributor patent grant.

The license change proccess

A license change is a social problem. You will need buy-in and agreement of your community. If the idea of a license change is received positively, you can:

1. Stop accepting contributions unless the contributors explicitly agree to relicense their changes to the new license.

2. Contact all copyright holders of all past contributions, and ask them to license their contributions to your project under the new license. You should keep a permanent record of their consent to this license change. Ideally you get a signed letter. In practice, I guess using GitHub issues would be OK. You can ping contributors in an issue with @example mentions.

   Note that the contributors don't always personally hold the copyright to their contributions, e.g. if the copyright belongs to their employer. You would then have to get permission from their employer at the time.

3. Wait for the responses to roll in. This may take multiple months. Remember that contributors may be on a vacation, may have shifted their focus away from open-source contributions, or may be dead. You can try to follow up if they don't respond in a reasonable time frame.

4. If everyone agreed, you can change all license headers and publish the project with the changed license.

A note on licensing new contributions differently in a GPL project

I see your pull request template specifies the MIT license. This is a great step to give you maximum flexibility during this relicensing.

But since your current license is GPL, any contributions are derivative of existing GPL code in the project and therefore also have to be GPL-licensed. Your contributors do not have the right to issue them under the new license unless you can give them the code under the new license, which requires that all previous contributions have been relicensed.

These changes are therefore not MIT-licensed, but the contributors have given you the option of relicensing them later under the MIT license or a compatible license. If a contributor has given you this option for all their contributions, there is no need to contact them about the license change.

Dealing with code where consent to license change could not be obtained

If not everyone agreed to the license change, this becomes more complicated.

• Silence is not consent! If someone does not respond, you have to assume that they oppose the license change.
• If a contributor died, note that their copyright term extends for 70 years after death in most jurisdictions. You can try to contact the current copyright owners, most likely the deceased contributor's estate.
• If you have anonymous or pseudonymous contributions, relicensing is exceedingly difficult and I won't discuss that here.

If a contributor only made very minor contributions that do not pass the “threshold of originality”, then these contributions are not subject to copyright and you do not need their permission to relicense the project including these licenses. Where this threshold is set depends on the case law in your jurisdiction. This threshold does not give you a right to use these contributions, but just a possible legal defence when accused of copyright violation in respect to these changes. I would be uncomfortable relying on this for anything more substantial than typo fixes.

You can track the license status independently for each file or component. The possible statuses are:

• The file or component still includes GPL code.
• All past and present contributors agreed to license change, but the file or component directly or indirectly depends on GPL code.
• All past and present contributors agreed to license change, and the file or component has no dependencies on GPL code.

Only in the last case can you update the file to display the copyright/license header for the new license. This might allow you to immediately relicense some components, if your project has a suitable architecture (a win for decoupling and inversion of control!). But while even one piece of GPL code is still present in the project, the project as whole remains subject to the GPL.

For the remaining GPL files, you can try to rewrite them so that they no longer include GPL parts. This is quite tricky because the GPL is a copyleft license: although the other authors of the file agree to the license change, their contributions are derived from GPL code so they can only license their changes under the GPL, not under the new license. It is therefore not sufficient to just rewrite any lines touched by a contributor who didn't agree to the license change. You will have to rewrite the complete file or component from scratch, preferably as a clean-room implementation.

As an additional difficulty, GPL code may have been copy–pasted within the project. Again, the pasted code and any code derived from the pasted code may not be relicensed until the original author has agreed to the license change. Auditing for this might be very difficult, unless the problematic contributions are fairly recent and comparatively minor.

Conclusion

Depending on your goals, resources, and community, this might be over fairly quickly, or be a long process that extends across multiple months or even years. And it could be the case that significant authors do not agree with the license change, thus requiring unreasonable effort to eliminate their contributions. In that case, you may want to accept that the project has been locked in to the GPL, and clarify your documentation to reflect this license.