Compatibility, legality and possible problems with the open source license change

Asked

Viewed 400 times

5

I made Fork of a free code software currently available under the LPG V2. Such a license has some obstacles, so I’m looking for ways to update the fruit of Fork to be more "fair".

The fruit product of Fork (by-product, let’s say) will continue to be freely available (something the original does not, since the question opensource of it is more marketing, including the repository is not even updated, while there are updates released in the form of updates), but fully restructured, removing currently existing Features that are not part of the scope of the proposal, inclusion of new Features, update to market opensource frameworks, etc.

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

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

I searched a lot about this "migration", but found nothing relevant, only brief comparative on the licenses in question.

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

I don’t know very well about open source software license, so I have a lot of questions and I want to start with the following on this issue:

  • Is there a problem in changing, in the by-product, the license of an open source software?
  • What problems can I have with the amendment and how to avoid them, given the above scenario?
  • Considering the problems, what would be a possible alternative to use two licenses, LPG V2 for what was "forkado" and GPL V3/Apache 2.0 for the new functionalities/features?

Any help is welcome =)

  • 1

    The GPL license specifies that any "derivative work" must be subject to the same terms as the original work. if A is GPL and you developed B, you can license B as you wish, but A + B accurate be GPL. This is intentional. Not everyone likes it (I for example do not like it), but it is a strategic decision on the part of the author, and needs to be respected.

  • Thanks for the help @mgibsonbr. For example, if I have X which is GPL, Gero X' derivative of X and all that is new in X' will be under, for example, ASF, if at a given time in X' I no longer have a subset of X, but only new fines, X' still needs to be GPL or can it be now all ASF? I don’t know if I was clear here rs

  • 2

    If I understand correctly, you left from x (LPG), changed to x + x'0, then to x + x'0 + x'1, x + x'0 + x'1 + x'2... Where each x'n is of your own making. Eventually you took x of the equation: x'0 + x'1 + x'2 + ... + x'n = x' - 100% of the code is your own. Theoretically so you could license as you please (ideas are not copyrighted, only concrete expressions of them). What is difficult is to achieve this in practice - there will always be something left on its basis that came from x. While x' for derivative of x, the whole must be LPG.

  • P.S. What is or is not a "derivative work" is something that the justice must decide. The FSF believes that all you have to do is link something in memory with your GPL program so that the whole is considered a derivative work, but not everyone agrees. This complexity discourages me from getting involved with the GPL, even if I agree with the ethical principles behind it. As useful as a GPL code is, I never incorporate it into my projects unless I’m willing to also use the GPL (which so far has been: never... : P)

2 answers

7


I don’t know how to help you with the specifics, so for your own safety I suggest you consult a lawyer. In the meantime, I would like to clarify some general principles on such licences copyleft to help guide you about its use.

Reciprocity

When a software author decides to make a product available as free software - waiving the right granted by law to receive royalties about the same - he does it 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 expect something in return: the reciprocity from 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 (i.e. giving up copyright, unrestrictedly). Symbolics enhanced these interpreters, but when Stallman requested access to the enhanced version his request was refused. The conception of the GPL license followed almost immediately (first a more restricted one, for Emacs, then a more general purpose one, GNU), in order to avoid this kind 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 you improve it somehow and redistribute it (enhance for private use does not require you to do anything). Some licenses copyleft (Affero type GPL) also require that access to sources is given even if it is offered as Saas.

You can consider these requirements reasonable or not, this is with the opinion of each one (as well as each has a different opinion as to the morality of charging for the mere copy of a software, which can be done at virtually zero cost). But the fact is that the licensee expects this reciprocity, on paper, and at first 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 the reciprocity

Okay, but what if I make my enhanced version available under a license more permissive that the GPL, will not be maintaining reciprocity? After all, I gave my users all the freedoms that their original product gave, and more... Unfortunately, it’s not that simple. Consider the following scenario:

  • Alice offers A as GPL;
  • Bob improves A, and provides B like MIT;
  • Charlie enhances B, and provides C under a proprietary licence;
  • Alice asks Charlie for the sources of C; Charlie denies;
  • Alice sues Bob for copyright infringement because his use of A violates the terms of the licence.

You might think, "but what Alice wrote is still free, what is not free is just what Charlie wrote, so she’s complaining about it?" but consider that for Alice it can be interesting strategically that your system remains free. Maybe she doesn’t earn directly with licenses, but she can earn her keep by servicing her product. If a competitor arrives with a better product, she runs the risk of being out of work.

The "X" of the issue here is that Charlie did not simply develop something better than Alice, and reaped the fruits of his own work: he used Alice’s product as a "stepping stone" to establish himself as her competitor.

If this sort of thing were so easy, the amount of free software on the market would hardly be so numerous. Because it would be restricted to hobbists in their spare time, professionals would eventually follow the same proprietary model, in which their perspective of return is more guaranteed.

Edge cases

The GNU GPL has been written very carefully to prevent all kinds of abuse that exploits "holes" in the law. Version 3 includes for example protections against "tivoization" (embedding free software in the hardware or firmware, preventing in practice its modification), or the use of patents to ensure the monopoly of an application despite the conditions of its license, etc. The principle behind the copyleft is important to many people, so I would not underestimate their ability (and disposition) to run after their rights.

Then responding to your questions:

Is there a problem in changing, in the by-product, the license of an open source software?

For the GPL, yes. In general, the software is made with the premise that will be modified, recombined and/or incorporated with other software, so the licenses already seek to deal with this scenario, albeit briefly. Licenses copyfree in general do not require much in this scenario except a correct attribution of the source (i.e. do not deny the authorship of the original). But pras copyleft this is important yes.

You cannot "relicense" something from which you do not own the copyright. In the world of copyright redistribution is the exception, not the rule, so you need to keep in mind that the permission the GPL gives you to redistribute is not a right yours, and yes a privilege in exchange for a counterpart. 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 amendment and how to avoid them, given the above scenario?

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

How to avoid them, simple: do not violate the terms of the GPL license. If your product is a "derivative work" of a GPL system, either in the most 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, the Law No 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 "forkado" and GPL V3/Apache 2.0 for the new features/features?

It depends: these "new features/features" are self-contained or not? In other words, in the absence of the original software, whether embedded or used together, your system fulfills its purpose, does anything useful? If yes, then it is a system apart, and being of your authorship you can license it as you wish. Otherwise, it is still considered a work derived from 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 it is difficult to state anything like that in the abstract. However, keep in mind that you are stepping on dangerous ground if you choose to deviate from the licensing model established by the original author.

  • Excellent answer, my man. I will now consider making one "from scratch", since in the other it would be necessary so many modifications that I think it makes impossible. Basically, only parts of the data model would remain the same in the derived software "final".

5

Not

Your project license is still a derivative work that is bound by the GPL restrictions. This means that you would have to release it under the same conditions as the GPL. You cannot release it under another license.

Note: I have no knowledge of the whole license

I believe that the point that speaks more explicitly that this is not allowed, would be this:

  1. You may copy and Distribute Verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately Publish on each copy an appropriate copyright notice and Disclaimer of Warranty; Keep intact all the notices that refer to this License and to the Absence of any Warranty; and Give any other Recipients of the Program a copy of this License along with the Program.

Translating:

Note: Translation may not be "accurate"

  1. You may copy and distribute copies of the source code when receiving it, by any means, provided that you conspicuously and appropriately publish in each copy an appropriate one copyright notice and warranty waiver; keep all notices referring to this License and the absence of any warranty; and provide other recipients of the Program with a copy of this License along with the Program.

More precisely this: (keep all the notices referring to this License)

And in the second section of the license we have this:

But when you Distribute the same sections as part of a Whole which is a work based on the Program, the Distribution of the Whole must be on the Terms of this License

You cannot create a sub-class that communicates with the parent class (which is GPL), the sub-class also that being GPL and by my understanding, this difficulty is why there is the LGPL license.

LPG

Other developers can lend and modify the code and redistribute it as part of their own project, only if their entire project is also licensed under the GPL.

This prevents the code from being used in proprietary software.

LGPL

Other developers may be loaned and modify the code and redistribute it as part of their own project, provided that the portion used under the LGPL is re-licensed under the LGPL. Other parts of the project are allowed have other licenses.

This allows the code to be used proprietary.

Note: In the issue of the GPL what communicates with it is that it has to be GPL too and for this reason maybe Google in the issue of Android have found such a loophole, I just have no details of how to do.

I believe, that if such open-source Fork was just a file py (Python) called produtoemgpl.py, with this content:

class ProdutoEmGPL:

    @staticmethod
    def metodoA(str):
        ...

    @staticmethod
    def metodoB(str):
        ...

And you want to add new features under another license, you should create a new file and extend the parent class, the file name would be minhaclasse.py and this would be under your other license:

import ProdutoEmGPL

class MinhaClasse(ProdutoEmGPL):

    @staticmethod
    def metodoA(str):
        ...

    @staticmethod
    def metodoB(str):

(I personally find it somewhat unfair that you want to change the license, regardless of how badly you feel about not having the updates in the repository.)

About such product, I believe that they should distribute the product of type "community" and for commercial use for example, you should acquire another license of themselves (for example buying, but still you will not be able to change the license probably)

Note: If you disagree with me please Negative or close, I really don’t have much knowledge about such a license.

Extra: How Open-Source Software Licensing Works?

  • Thank you for your help, William. It’s not a matter of injustice, but just making something available that really means something to the community. See the case of Android when Google adopted ASF, for example. About what you said, you can quote fonts, excerpts, etc?

  • OK, thank you William. I will see your answer carefully and see how to combine the licenses. I really understand that I can’t just pick up X which is GPL, generate X' and this last ASF being, or something. Perhaps the question is not clear, I will check, but the intention is not to change what is already licensed under GPL, but to offer the news in X' under another license. For example, everything old or set in X continues GPL, all new in X' under another license. Then, in the end, you may have everything under another license, you understand?

  • On android, at the time, had a great discussion of the way it would be licensed, since it is under things in GPL, as the kernel. So they kind of "split", some things are GPL (like kernel contributions) and what’s bought is ASF. Anyway, it was just a case that in parts is similar. In my case it is a product, but not compiled, there are old versions of the code available. The context is quite close to the Hudson/Jenkins I mentioned, differing in the licenses.

  • @Brunswick I don’t really know if this is the best way, but my latest issue is an assumption of what I believe you can do, but maybe you could consult someone else.

  • Cool William, thank you very much. Let’s wait and see if anyone else gives more good suggestions as yours, thank you very much.

  • In my view, by simply importing the GPL system you are causing both to occupy the same memory address space, and according to the FSF (not necessarily according to justice) this constitutes a "derivative work". The whole would then have to be distributed according to the GPL.

  • @mgibsonbr Yes it seems that you are correct, to my understanding, you can distribute B in another license yes, but you cannot distribute together with A (which is in GPL), the user would have to download "A" for it. This was my understanding. If I’m not mistaken this issue is one of the reasons for the LGPL license.

  • Not so much, there is no problem in distributing free and non-free software in the same set (on a CD, for example), the problem is the two softwares interact with each other - regardless of how they were distributed.

  • @mgibsonbr so the problem really is in the communication between them. Just a theory, I know discussions here aren’t cool, but I’ll get an assumption: If I have "A" (GPL) and "B" (GPL - developed by me) and this B generate data for a json file for example, then I would have "C" (MIT) that would take this json, this would not be direct communication and would be allowed?

  • Communicating even is not a problem, even if a non-free system wants to invoke a free via Fork/exec or vice versa, passing data via stdin and reading the answer via stdout, the GPL allows. They are stronger integrations, which could make it impossible to separate the two, which are problematic.

Show 5 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.