[Matroska-general] License Form for TCME
suiryc at yahoo.com
Fri Jan 30 13:28:53 CET 2004
--- Christian HJ Wiesner <chris at matroska.org> wrote:
> there has been a lot of discussion about the license for TCME, before
> even a single line was coded, but thats actually not a bad thing
> Here the options and the Pro's / Con's , in a summary :
> *1. Closed source / no license :*
> Pro : allows selling ; no forks possible ; all binaries fully
> controllable with respect to their functionality
> Con : nobody from outside will contribute to it, we have to do
> everything ourselves ; bad commercial reputation
> My vote : not a bad option with some advantages, but not my favourite
Closed source means you won't get a lot of supports from 'free' coders.
Such a huge project will already progress slowly so ... :p
> *2. QPL / GPL dual license*
> Pro : allows selling of the program later, for everything contributed
> under the QPL license
> Con : contributors can choose either license for for their patches,
> doesnt prevent forking at all
> My vote : BAD !
Indeed not the best solution if you want to merge changes made under
the GPL license by other people, and plan to sell the code :p
> *3. QPL single license*
> Pro : Makes forking not so easy, and always obvious to informed users
> allows selling of the program ; patches sent by contributors can be
> Con : Gives the whole project a bad, commercial smell, even if we
> plan to market the program
> My vote : We have better options
As I already said I don't think QPL will prevent determined people from
forking the project. So it is good only for comercial reasons (and in
this case bad for the people who contributed by patches since only the
original authors will get something).
> *4. GPL single license*
> Pro : well accepted license type with good reputation in the OSS
> community ; contributors will feel safe about doing so ; free
> from the GNU lawyers in case a company will steal the code ; lot of
> out there that could be reused
> Con : an invitation to fork the project, as GPL is pro-fork
> My vote : maybe the best option we have, if we dont make 5.
Yes it allows forking. But as explained by Mosu when this happens it's
generally all for the best ;).
> *5. New license, 'Corecodec Public Antifork License'*
> Explanation : We can basically copy some paragraphs from the GPL, but
> add other paragraph to strictly forbid to fork from the project,
> the complete source/binary distribution has to be changed compared to
> the GPL, making it ( of course ) completely incompatible with the GPL
> itself ; special paragraphs have to deal with what's happening in
> - the original host ( Corecodec ) disappears, and the devs cant agree
> a new host
> - the project is declared dead by the majority of the main
> - the originall devs decide to relicense and sell the code
> For these cases a 'fallback to GPL' should be part of the license,
> making the program free-software in the terms of the FSF again, to
> abuse and to help contributors to trust in the goals. I expect that
> other projects may also have a use for the license that way.
> Pro : raises public awareness for Corecodec, especially if we manage
> get OSI approval for it ( i checked many other licenses, there is no
> similar license existing )
> Con : people will instantaneously cry : 'yet another license, and why
> ; higher explanation effort
> My vote : lets discuss that here, i'd love to hear your opinions
Doing yet another license require time and money (you certainly need to
hire a lawyer to ensure the new license will do exactly what you
Moreover this new license, due to its restriction, will likely be
listed as 'incompatible with GPL' and thus prevent many people from
So I am also for a GPL license.
BBB mentioned on IRC that he was using L-GPL even for programs (because
he found it more convenient). Maybe he could join the discussion and
explain why LGPL could be better than GPL for programs.
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
More information about the Matroska-general