[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] License is too restrictive for real-world use.

From: Nids
Subject: Re: [Tinycc-devel] License is too restrictive for real-world use.
Date: Wed, 2 Mar 2016 15:51:54 +0000

Let me just clarify one point because probably that got lost in translation.

Suppose that you are building *closed* source software A using the library B that is covered by the LGPL license. Two main cases exist:

1. You create your application A *without* modifying library B: *no problem*, this is the most common case (e.g., all the applications compiled with g++ and using the STL library coming with it, as the GNU STL is released under LGPL).

2. You create your application A and you need to *modify* library B (let's call the modified version B') and, as a consequence of this, you need to statically compile B' into A or to distribute the shared library B' with A: you need to make your changes available to *anyone* requesting them as the LGPL states explicitly that. You can distribute them under request, distribute the source together with the binary of A or made them available on a webpage and pointing to it in the documentation of A. This would mean that you are actually creating a "fork" of B.

If, in case 2, you fail to comply with providing the B', that is not a *moral* problem but a *legal* one: licenses are legal contracts and you can be taken to court if you fail to comply.

What *usually* happens, if you need to create B' out of B, is to contribute back your changes to B. This not only for some ideological reasons but also because it has a positive effect on *your* work as well: if you do *not* merge your changes from B' into B, every time that B gets new patches and improvements you have to port them to your custom library in order to benefit from them. Moreover, merging your changes from B' into B can improve them at *no cost* for you because more people can contribute to them with fixes, etc.

Now, if to create A, you need to modify so *heavily* B that afterwards it will not even be recognizable, why using B in the very first place and complicate your life?

My £0.02

Typed on a very small keyboard...

From: John B
Sent: ‎02/‎03/‎2016 12:43
To: address@hidden
Subject: Re: [Tinycc-devel] License is too restrictive for real-world use.

Hi Daniel, thank you for your replies.  I am going to bow out of this thread for a while.  My advice to you and everyone is to stop assuming the worst in others or inferring their motives.  Also I think you are mistaken about bsd, but even if you aren't that's fine.  Bottom line bsd eliminates the need to reveal derivative work.  Everyone still has access to the underlining original source.  People give e.g. Microsoft a bad time for using bsd, but did they magically remove the open source code from existence all because they used it? uh no.

And by de-identified I mean... releasing my version of the library to the open source community, and maybe it will be useful to somebody in a novel way I don't know.  Honestly my software is geared more towards statisticians than really anyone else  (coming back to my original praise for jit-expressions).  So at the same time I do that open-source give back, I am also releasing my application separate to that in a completely different setting and nobody will be able to marry the two together.  It'll be stripped of an identifiable information that ties back to the application. Now  I would have as much interest to see the library gain strength as anyone if I am a consumer of it.  So you can buy my software and you can go to some open source community and see this library... but you'll never know they were the same entity much like some people still don't know coca-cola own minute-maid.  So that is what I mean by releasing my derivative in a de-identified way.  I guess it is a term we use at work when you have object A and object B and you have legal requirements to make sure you cannot prove a relationship between them.  The flip side to this is to explicitly declare that relationship lest you be in contempt of the license rules.  Hope that makes more sense.  So I know I would be willing to release whatever you can think of so long as you don't know how my program was built.  It is not like tiny_cc is doing something conceptually that nobody knows about, it's a compiler

From: address@hidden <address@hidden> on behalf of Daniel Glöckner <address@hidden>
Sent: Wednesday, March 2, 2016 4:20 AM
To: address@hidden
Subject: Re: [Tinycc-devel] License is too restrictive for real-world use.

On Wed, Mar 02, 2016 at 11:01:04AM +0000, John B wrote:
> Also I was hoping maybe a previous version of it that didn't include
> as many devs on-boarding from the 2013 version could be changed.  Thus
> nulling out the sign-off on devs that came afterwards.

My first contribution was merged in 2003 if you are looking for older

> Because bsd license I believe would be 100x healthier for the project.

It sounded like you wanted to keep it a secret in your product that is
would be based on TinyCC. That is in violation of the second clause of
the BSD license. The MIT license has a similar clause (actually it is
more similar to the first BSD clause but not restricted to source code).

> People would absolutely contribute back, but in a de-identified way.
> I Absolutely believe this.

So you would contribute back everything if it was BSD?

What do you mean by "de-identified"?

Best regards,


Tinycc-devel mailing list
Tinycc-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]