Question:

I forked open source software currently available under the GPL V2 . Such a license has some snags, so I'm looking for ways to update the fork's fruit to be more "fair".

The product resulting from the fork (by-product, let's say) will continue to be freely available (which the original does not do, since its opensource issue is more marketing, including the repository is not even updated, while there are updates released in the form of updates ), but completely restructured, removing currently existing features that are not part of the scope of the proposal, including new features, updating to market opensource frameworks, etc.

Until then I am considering the Apache 2.0 , MIT and GPL V3 licenses with preference for Apache 2.0, due to facts such as:

• changes made may be proprietary, so other people could fork their own products, just keeping the credits;
• it is not copyleft , I believe that this would lower the barrier in the adoption of all or parts of the product in other initiatives, both opensource and proprietary;

I searched a lot about this "migration", but I didn't find anything relevant, just brief comparisons about the licenses in question.

I looked at the Hudson/Jenkins case, a scenario very similar to mine, but Hudson was under the MIT license, much simpler, being changed to the Eclipse Public License – v 1.0 and Jenkins continuing at MIT .

I don't know very well about licensing open source software, so I have a lot of questions and I want to start with the following in this question:

• Is it okay to change the license for an open source software in the by-product?
• What problems can I have with the change and how can I avoid them, considering the aforementioned scenario?
• Considering the problems, what would be a possible alternative to use two licenses, GPL V2 for what was "forked" and GPL V3 / Apache 2.0 for the new features/features?

Any help is welcome =)

Answer:

I don't know how to help you with the specific details, for your safety I suggest you consult a lawyer. However, I would like to clarify some general principles about such copyleft licenses to help guide you in their use.

Reciprocity

When a software author decides to make a product available as free software – giving up the right granted by law to receive royalties on the same – he does so for some reason. At first, it could simply be the willingness to contribute to the community, without receiving anything in return, but not always. Many do expect something in return: the reciprocity of those who receive a copy of their product in keeping it free.

According to Wikipedia , Richard Stallman had worked on a Lisp interpreter for a few years, and agreed to make it available to Symbolics via the public domain (ie waive his copyright, unrestrictedly). Symbolics improved these interpreters, but when Stallman requested access to the enhanced version, his request was refused. The design of the GPL license followed almost immediately (first a more restricted one, for Emacs, then a more general purpose one, for GNU), in order to avoid this type of situation.

The reciprocity required is quite simple in principle: I give you plenty of freedom to use my software, without charging anything [recurring] for it, and in return you agree to do the same if I improve it in any way and redistribute it. lo (enhancing for private use doesn't force you to do anything). Some copyleft licenses (like the Affero GPL) also require access to sources even though they are offered as SaaS.

You can consider these requirements reasonable or not, that's up to everyone (as well as everyone has a different opinion on the morality of charging for the mere copy of software, which can be done with virtually zero cost). But the fact is that the licensee expects this reciprocity, on paper, and in principle is ready to take legal action against those who do not honor it (and with the support of several organizations that defend free software, such as the FSF).

hurting reciprocity

Okay, but what if I make my enhanced version available under a more permissive license than the GPL, am I not maintaining reciprocity? After all, I've given my users all the freedoms your original product did, and then some… Unfortunately, it's not that simple. Consider the following scenario:

• Alice makes A available as GPL;
• Bob improves A , and makes B available as MIT;
• Charlie improves upon B , and makes C available under a proprietary license;
• Alice asks Charlie for C 's sources; Charlie denies it;
• Alice sues Bob for copyright infringement as his use of A violates Bob's license terms.

You might think "but what Alice wrote is still free, what isn't free is just what Charlie wrote, so what is she complaining about?", but consider that for Alice it might be strategically interesting for her system to remain free. Maybe she doesn't earn directly from licenses, but she can earn her living by providing services on top of your product. If a competitor comes up with a better product, she risks running out of work.

The "X" of the issue here is that Charlie didn't simply develop something better than Alice, and reap the rewards of his own work: he used Alice's product as a "step" to establish himself as a competitor.

If this kind of thing were so easy, the amount of free software on the market would hardly be that numerous. As it would be restricted to hobbyists in their spare time, professionals would end up following the same proprietary model, in which their prospect of return is more guaranteed.

edge cases

The GNU GPL was written with great care to avoid any kind of abuse that exploits "holes" in the law. Version 3 includes, for example, protections against "tivoization" (embedding free software in hardware or firmware, preventing its modification in practice), or the use of patents to guarantee the monopoly of an application despite the conditions of its license, etc. The principle behind copyleft is important to many people, so I would not underestimate their ability (and willingness) to pursue their rights.

So in response to your questions:

Is it okay to change the license for an open source software in the by-product?

For the LPG, yes. In general, software is made with the premise that it will be modified, recombined and/or incorporated with other software, so the licenses already seek to address this scenario, albeit briefly. Copyfree licenses generally don't require much in this scenario, other than correct attribution of the source (ie not denying authorship of the original). But for copyleft this is important indeed.

You cannot "relicense" something that you do not own the copyright to. In the world of copyright , redistribution is the exception, not the rule, so keep in mind that the permission the GPL gives you to redistribute is not your right , but a privilege granted in exchange for consideration . If you do not agree or are unwilling to give this consideration, you lose the privilege of being able to redistribute the by-product. It's that simple.

What problems can I have with the change and how can I avoid them, considering the aforementioned scenario?

As explained, redistributing is not your right, but a privilege, so if you do not comply with the provisions of the license you lose this privilege, and your redistribution becomes copyright infringement . The consequences of that, I'd say are more or less the same as you making a copy of Microsoft Windows and redistributing it… Conceptually, at least, to be sure only an expert on these legal issues could tell.

How to avoid them, simple: don't violate the terms of the GPL license. If your product is a "derivative work" of a GPL system, either in the more technical sense (any program that runs in the same address space as the GPL program) or in a broader sense, in accordance with the legal provisions of your region ( in Brazil, Law Nº 9.610 ), and you choose to redistribute it, do so also under the GPL license, same version or – if the product has been licensed as "GPL version 2 or higher " – a higher version.

Considering the problems, what would be a possible alternative to use two licenses, GPL V2 for what was "forked" and GPL V3/Apache 2.0 for the new functionalities/features?

So it depends: are these "new features/features" self-contained or not? In other words, in the absence of the original software, whether embedded or used together, does your system fulfill its purpose, do something useful? If so, then it is a separate system, and being your own authorship, you can license it as you see fit. Otherwise, it is still considered a derivative work of the original, so it must comply with the terms of the original product.

The possibilities of structuring your system so that they are or are not independent of the original are quite diverse, so that it is difficult to state anything like that in the abstract. However, keep in mind that you are treading on dangerous ground if you choose to deviate from the licensing model established by the original author.