You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current license for GCViewer is LGPL which limits how the users can use the software. In practice, many projects can't really use GCViewer as a library because of LGPL restrictions, and the only use is "ad-hoc manual use".
There are lots of cases when LGPL dependencies were removed from the ASF projects. Even though LGPL "allows" users to link with unmodified software. The thing is users do not know if they would need to modify the dependency in future, and if they depend on LGPL, and later they decide they need modifications, they are in trouble: you need to deal with licensing, etc, etc. On the other hand, Apache 2.0 license provides users with clear picture on how they can modify the software should they need that.
Here's a recent example where Apache Airflow team convinced requests library from Python to remove dependency on LGPL-licensed chardet: https://issues.apache.org/jira/browse/LEGAL-572
I believe that is not the only case when the ASF convinced other projects that LGPL is not quite right for the libraries.
So here's my question: do you really want to limit users on the way they can use GCViewer?
Do you expect that there are valid reasons to split "parser" and "UI" into different jars (modules) so people can use the parser from the command line or integrate into other UIs?
If you expect that you allow people to use GCViewer as a library, then the better license would be Apache 2.0
The text was updated successfully, but these errors were encountered:
You cannot simply change the license for old code.
People have contributed to GCViewer under specific terms—this includes the license. IMO, the very least you'd have to do, is to ask all contributors (for example via mentions) for their agreement to a license switch within a certain period of time (for example, allow one month to answer) and if nobody disagrees within this period, do the switch then.
To ensure a smoother license switch next time, you might want to add contribution guidelines that clearly state that contributors must accept license changes.
That said, as the original author of CGViewer, I'd be perfectly fine with a switch to Apache 2.0.
The current license for GCViewer is LGPL which limits how the users can use the software. In practice, many projects can't really use GCViewer as a library because of LGPL restrictions, and the only use is "ad-hoc manual use".
For instance, Apache Software Foundation forbids depending on LPGL-licensed software (see https://www.apache.org/legal/resolved.html#category-x ) because it
Places restrictions on larger works
There are lots of cases when LGPL dependencies were removed from the ASF projects. Even though LGPL "allows" users to link with unmodified software. The thing is users do not know if they would need to modify the dependency in future, and if they depend on LGPL, and later they decide they need modifications, they are in trouble: you need to deal with licensing, etc, etc. On the other hand, Apache 2.0 license provides users with clear picture on how they can modify the software should they need that.
Here's a recent example where Apache Airflow team convinced
requests
library from Python to remove dependency on LGPL-licensedchardet
: https://issues.apache.org/jira/browse/LEGAL-572I believe that is not the only case when the ASF convinced other projects that LGPL is not quite right for the libraries.
So here's my question: do you really want to limit users on the way they can use GCViewer?
Do you expect that there are valid reasons to split "parser" and "UI" into different jars (modules) so people can use the parser from the command line or integrate into other UIs?
If you expect that you allow people to use GCViewer as a library, then the better license would be Apache 2.0
The text was updated successfully, but these errors were encountered: