IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
TAK - Source code release and conversion, From Topic ID: 50958
kwanbis
post Jan 30 2007, 22:26
Post #26





Group: Developer (Donating)
Posts: 2353
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (rjamorim @ Jan 30 2007, 13:26) *
What, in God's name, are you talking about?

they took all that was made with WINE, and created a closed source derivative.

Then WINE changed to GPL.

QUOTE (rjamorim @ Jan 30 2007, 13:26) *
And no, LGPL won't get TAK far with regards to hardware support.

Why not?


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
rjamorim
post Jan 30 2007, 22:55
Post #27


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (kwanbis @ Jan 30 2007, 18:26) *
they took all that was made with WINE, and created a closed source derivative.

Then WINE changed to GPL.


Dude, you have no clue whatsoever.

1 - Wine was never BSDish. It was first licensed under the MIT license, and later under the LGPL. It was never under the GPL either.

2 - CodeWeavers - makers of Crossover Office - pretty much OWNS wine. They also hire the Wine project leader, Alexandre Julliard, and several other key developers. So, it's the other way around: you should be thanking CodeWeavers for releasing parts of their software under the LGPL.

3 - To this day, they still contribute lots of code back to Wine.

QUOTE
Why not?


Corporate mindset. Go figure it out.

This post has been edited by rjamorim: Jan 30 2007, 23:00


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
kwanbis
post Jan 31 2007, 14:18
Post #28





Group: Developer (Donating)
Posts: 2353
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (rjamorim @ Jan 30 2007, 21:55) *
Dude, you have no clue whatsoever.

i probably have too many things on my head ...

QUOTE (rjamorim @ Jan 30 2007, 21:55) *
1 - Wine was never BSDish. It was first licensed under the MIT license, and later under the LGPL. It was never under the GPL either.

sorry, i mean LGPL (i was asking for LGPL, remember?).

QUOTE (rjamorim @ Jan 30 2007, 21:55) *
CodeWeavers - makers of Crossover Office - pretty much OWNS wine. They also hire the Wine project leader, Alexandre Julliard, and several other key developers. So, it's the other way around: you should be thanking CodeWeavers for releasing parts of their software under the LGPL.

i actually thought it was a problem with codeweavers ... but no ... anyway, the important thing, is that a company like codeweavers, was worried about the MIT (per your comments) type license, and wanted the LGPL, to protect WINE and themselves .... here is an open letter:

Jeremy White, the CEO of CodeWeavers, a major contributor to the WINE project, has put forward a strong proposal that the license of WINE be changed from its currently BSD-style terms to a GPL or LGPL ("xGPL") license instead. The change, if implemented, would ensure that all enhancements or extensions made to WINE by any individual or company would be available to benefit the WINE project. With the proposed new license, if you start from WINE source and modify or enhance what you get, you must make what you have done available to the WINE project -- which is a fundamental principle of the GNU General Public License (GPL) under which the Linux kernel is released. White says his motivation is to prevent companies from taking WINE and turning it into a closed, proprietary product, which is permitted by the current BSD-style license.

Here is Jeremy White's open letter to the WINE community . . .

QUOTE
Subject: Wine license change
From: Jeremy White (jwhite@codeweavers.com)
Date: Wed Feb 06 2002 - 17:54:05 EST

Folks,

Some recent events have occurred that have made me change my opinion about a Wine license change.

During my involvement in the Wine project, I have always striven to make sure that I, and my company, did what was best for the Wine project. I believe Wine's success will help to make the world a better place. To that end, often through difficult personal negotiations, I have always insured that all of my contracts require that all code changes be returned to Wine. This, in effect, treats Wine as an LGPL product.

You can argue that the flexibility granted by the Wine license has meant that I received some business I would not otherwise have had. Gav, for example, has pointed out that Corel would never have worked on Wine if not for its license. There are two ironies there - first, Corel has always been a great Wine citizen, IMO, never 'abusing' the license. Second, while we did work with Corel to help them with Wine, we never signed a contract with them. Their lawyers and I were never able to agree on a contract that we thought would sufficiently protect Wine. Fortunately for me, we were able to work with Corel without a contract, but this issue to this day creates unnecessary friction between my company and Corel.

However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's.

Thus, I would like to call for a change in the Wine license. I think we all agreed that the LGPL formed the basis for a good 'alternate' license strategy. Eben Moglen, the counsel for the FSF, has kindly offered to help review licensing strategies for Wine. The goal is to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine. I think it it is great that we have, in Eben, not only the leading legal scholar on free software licensing, but a great hacker to boot. I think he will clarify exactly what is possible and what is not possible with GPL style licenses and insure that the license we choose will meet our goals.

When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license.

I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows:

Should the Wine project switch to a license which has as its goal to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine?

Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend.

Thanks,

Jeremy


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
rjamorim
post Jan 31 2007, 15:17
Post #29


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



Ok, I see you still have very little clue of what is going on. Let me explain:

1 - Wine was released under the MIT license

2 - Transgaming took the sources and made Cedega

3 - People at wine/CodeWeavers freaked out and moved on to the LGPL

4 - Neverthless, Transgaming contributed lots of code back to wine, making the hysteria at the CodeWeavers camp a moot point.


Anyway, the point remains that, if TBeck releases the sources under the LGPL, he won't see much hardware support, if any. CodeWeavers chose the LGPL specifically to avoid people (other than themselves) making money out of it. If that was TBeck's goal, I wouldn't expect him to be warmly welcomed by hardware makers.

I think you can imagine Xiph considered all that when choosing their license of choice. Still, they went with BSD instead of LGPL. Can you guess why?


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
TBeck
post Jan 31 2007, 15:43
Post #30


TAK Developer


Group: Developer
Posts: 1095
Joined: 1-April 06
Member No.: 29051



QUOTE (rjamorim @ Jan 31 2007, 15:17) *
Anyway, the point remains that, if TBeck releases the sources under the LGPL, he won't see much hardware support, if any. CodeWeavers chose the LGPL specifically to avoid people (other than themselves) making money out of it. If that was TBeck's goal, I wouldn't expect him to be warmly welcomed by hardware makers.

Only a first guess, because i have to learn far more about those licenses (when it's time, not now) before making my choice.

Possibly i will use different licences for the encoding and decoding part:

1) BSD for the decoder to achieve maximum hardware playback support. It's perfectly ok if hardware bound decoders are closed source. In what important aspect could they be optimized by the developers? Specific optimizations for their hardware i suppose. And because they are hardware specific, they anyhow would be of little use for TAK's mainstream library.

2) Possibly i would prefer GPL or LGPL for the encoder part, to have the opportunity to check the compatibility of possible improvements performed by others to TAK's specification.
Go to the top of the page
+Quote Post
rjamorim
post Jan 31 2007, 15:55
Post #31


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (TBeck @ Jan 31 2007, 11:43) *
1) BSD for the decoder to achieve maximum hardware playback support. It's perfectly ok if hardware bound decoders are closed source. In what important aspect could they be optimized by the developers? Specific optimizations for their hardware i suppose. And because they are hardware specific, they anyhow would be of little use for TAK's mainstream library.


Besides that, there's the point of the corporate mindset I mentioned before. "We are going to invest time and resources on optimizing it for our platform, and if we open source the changes we make, some competitor with a similar platform will just take our work and use it freely. No thanks, we'll go with FLAC."

QUOTE
2) Possibly i would prefer GPL or LGPL for the encoder part, to have the opportunity to check the compatibility of possible improvements performed by others to TAK's specification.


Erm, no. The GPL won't prevent people from creating forks (if that's what you want).

You would need the QPL for that, but I strongly advise against it, because any project using QPL strongly stinks of being a project that will just grab improvements submitted by third parties and close them back into some non-free form.

(more specifically, you can fork software under the QPL, but you can't distribute the original QPL'd code - you must distribute your own code as patches against the original)

Oh, and all legal disputes about the license must happen in Oslo laugh.gif


The way for you to guarantee compatibility is actually quite easy: determine that you are the definitive source for the TAK specification and reference implementation. If someone else wants to improve it and break compatibility, it's his problem.

The effects that GPL would have on your code would be that
1 - FLAC and WavPack wouldn't be able to benefit from your code (but maybe from your ideas, if they reimplement them) because it would taint their BSD license
2 - It would be forbidden to include it with closed source software. For instance, Winamp wouldn't be able to bundle your encoder, like they do with FLAC.

A solution to (2) would be using the LGPL instead of GPL.

There will be no protection against people appropriating your ideas (as we discussed before) and the crediting guarantee will be pretty much the same as if you used BSD.

This post has been edited by rjamorim: Jan 31 2007, 16:03


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
kwanbis
post Jan 31 2007, 16:12
Post #32





Group: Developer (Donating)
Posts: 2353
Joined: 28-June 02
From: Argentina
Member No.: 2425



QUOTE (rjamorim @ Jan 31 2007, 14:55) *
Erm, no. The GPL won't prevent people from creating forks (if that's what you want).

In practice it does, as you can include all of the fork code into yours, if you feel like.

But yes, if the fork is a "conceptual" one, i mean, you want to go one way, the forker another, it can't prevent it.


--------------------
MAREO: http://www.webearce.com.ar
Go to the top of the page
+Quote Post
TBeck
post Jan 31 2007, 16:15
Post #33


TAK Developer


Group: Developer
Posts: 1095
Joined: 1-April 06
Member No.: 29051



QUOTE (rjamorim @ Jan 31 2007, 15:55) *
QUOTE (TBeck @ Jan 31 2007, 11:43) *
1) BSD for the decoder to achieve maximum hardware playback support. It's perfectly ok if hardware bound decoders are closed source. In what important aspect could they be optimized by the developers? Specific optimizations for their hardware i suppose. And because they are hardware specific, they anyhow would be of little use for TAK's mainstream library.

Besides that, there's the point of the corporate mindset I mentioned before. "We are going to invest time and resources on optimizing it for our platform, and if we open source the changes we make, some competitor with a similar platform will just take our work and use it freely. No thanks, we'll go with FLAC."

Exactly. My text was meant as an addition to this important point.

QUOTE (rjamorim @ Jan 31 2007, 15:55) *
QUOTE
2) Possibly i would prefer GPL or LGPL for the encoder part, to have the opportunity to check the compatibility of possible improvements performed by others to TAK's specification.

You would need the QPL for that, but I strongly advise against it, because any project using QPL strongly stinks of being a project that will just grab improvements submitted by third parties and close them back into some non-free form.

(more specifically, you can fork software under the QPL, but you can't distribute the original QPL'd code - you must distribute your own code as patches against the original)

The fact, that i never heard about an important QPL project, possibly should tell me something (besides me beeing ingnorant)...

QUOTE (rjamorim @ Jan 31 2007, 15:55) *
The way for you to guarantee compatibility is actually quite easy: determine that you are the definitive source for the TAK specification and reference implementation. If someone else wants to improve it and break compatibility, it's his problem.

The effects that GPL would have on your code would be that
1 - FLAC and WavPack wouldn't be able to benefit from your code (but maybe from your ideas, if they reimplement them) because it would taint their BSD license
2 - It would be forbidden to include it with closed source software. For instance, Winamp wouldn't be able to bundle your encoder, like they do with FLAC.

A solution to (2) would be using the LGPL instead of GPL.

Ok, probably BSD is a good option for the encoder too.

This post has been edited by TBeck: Jan 31 2007, 16:21
Go to the top of the page
+Quote Post
rjamorim
post Jan 31 2007, 16:26
Post #34


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (kwanbis @ Jan 31 2007, 12:12) *
QUOTE (rjamorim @ Jan 31 2007, 14:55) *

Erm, no. The GPL won't prevent people from creating forks (if that's what you want).

In practice it does, as you can include all of the fork code into yours, if you feel like.

But yes, if the fork is a "conceptual" one, i mean, you want to go one way, the forker another, it can't prevent it.


huh.gif

whatever


QUOTE
The fact, that i never heard about an important QPL project, possibly should tell me something


Qt. Is the only one. And it is dual-licensed under the GPL too.

Another thing I was thinking about the QPL: it would be a dumb choice, because some specific cases will actually require the encoder to be modified and compatibility broken. David Bryant mentioned situations where a developer had to break wavpack in clever ways to fit his needs (and it was OK, because the resulting files weren't meant to be played on winamp or decoded with official wvunpack). Keeping people from distributing these modified encoders wouldn't be very nice...

QUOTE
Ok, probably BSD is a good option for the encoder too.


I agree. The GPL won't give you much more protection than the BSD, and could actually hamper the format's popularity.

This post has been edited by rjamorim: Jan 31 2007, 16:30


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
Shade[ST]
post Jan 31 2007, 17:01
Post #35





Group: Members
Posts: 1189
Joined: 19-May 05
From: Montreal, Canada
Member No.: 22144



@Tom : You might want to check out www.sosinvention.com
Go to the top of the page
+Quote Post
rjamorim
post Jan 31 2007, 17:14
Post #36


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE
' date='Jan 31 2007, 13:01' post='468403']
@Tom : You might want to check out www.sosinvention.com


Is that site some sort of scam?


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
...Just Elliott
post Jan 31 2007, 22:57
Post #37





Group: Members
Posts: 446
Joined: 13-August 06
Member No.: 34002



QUOTE (rjamorim @ Jan 31 2007, 16:14) *
QUOTE
' date='Jan 31 2007, 13:01' post='468403']
@Tom : You might want to check out www.sosinvention.com


Is that site some sort of scam?

looks like it

but apparently it's reputable

i wouldn't use it.


--------------------
err... i'm not using windows any more ;)
Go to the top of the page
+Quote Post
rjamorim
post Jan 31 2007, 23:42
Post #38


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (...Just Elliott @ Jan 31 2007, 18:57) *
but apparently it's reputable


Where did you find about its reputability?

I searched the web high and low for third party opinions about their services and the legality of their "solution", and came out empty-handed.

All in all, it sounds too suspicious. If it really worked, nobody would be filing patents - it's much easier and cheaper to obtain copyrights on something, and they last much longer!


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
bhoar
post Feb 1 2007, 18:00
Post #39





Group: Members (Donating)
Posts: 612
Joined: 31-May 06
Member No.: 31326



Some thoughts:

On forking: it is probably best to investigate both Trademarking of the name (if not already trademarked...) as well as licenses that cover forking rules, such as the the license used for truecrypt: < http://www.truecrypt.org/license.php >. That license makes it clear that modifications/forks *cannot* use the truecrypt name. The reasoning for that has to do more with security/trust issues in this case, but I thought it should be noted here.

On choice of license: I will reiterate that if you own all of the code, and you ensure that you never incorporate code owned by others, you can bi- or tri- license your code. BSD (or the stronger GPL) releases to prevent thankless incorporation into closed source products (or any at all), plus private licenses of the same code to hardware people. My point is that you don't have to worry about scaring away hardware companies by your choice of public-release license, as they can always negotiate with you for a direct license.

Note: the truecrypt example may not compatible with public/private license examples given, of course.

-brendan

This post has been edited by bhoar: Feb 1 2007, 18:02


--------------------
Hacking CD Robots & Autoloaders: http://hyperdiscs.pbwiki.com/
Go to the top of the page
+Quote Post
...Just Elliott
post Feb 3 2007, 13:42
Post #40





Group: Members
Posts: 446
Joined: 13-August 06
Member No.: 34002



IMO, the more restrictive you want to be with your code, the less point there is to open source it. If you want protection from all that, well, keep your source :-)

QUOTE (rjamorim @ Jan 31 2007, 22:42) *
QUOTE (...Just Elliott @ Jan 31 2007, 18:57) *
but apparently it's reputable


Where did you find about its reputability?

I searched the web high and low for third party opinions about their services and the legality of their "solution", and came out empty-handed.

All in all, it sounds too suspicious. If it really worked, nobody would be filing patents - it's much easier and cheaper to obtain copyrights on something, and they last much longer!

I've seen it mentioned on a few forums with following discussion, but I couldn't give a direct source, sorry...


--------------------
err... i'm not using windows any more ;)
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st April 2014 - 08:11