headers
Ulrich von Zadow | 1 Nov 2005 01:16
Picon
Picon

Re: Anyone use LGPL code?

Mick West wrote:

> I think the problem here is that LGPL is a somewhat novel form of 
> contract that has little or no legal precedence.  Has there ever been a 
> lawsuit alleging violation of GPL (let alone LGPL) that been has worked 
> through to judgement in American courts?

I don't know about american courts, but we've had a case here in Germany 
where GPL'd code (the Linux netfilter implementation, if I remember 
correctly) turned up in closed-source routers. The result was that the 
company had to publish the code linked to GPL code. Since games are 
distributed world-wide, legal problems in any country can lead to things 
like this.

That said, I think clearing license issues is in many cases a matter of 
an email or two to the copyright holder. I've had people approach me for 
written permission to use my open-source libraries. I had the 
opportunity to check that they were complying to how I meant the library 
to be used and gave them the security they wanted. YMMV, but you don't 
really risk anything by taking this route.

 >  To me using LGPL code
> feels a little like taking a dubious tax deduction - when you do it, you 
> benefit, nothing bad happens, but you sleep a little less at night, 
> thinking "what if I get audited".

If you're not complying to the licensing terms, you're on dangerous 
terrain. I imagine disgruntled employees, tell-tale library bugs and 
other similar things can cause these things to surface...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Trout | 1 Nov 2005 01:25

Re: Anyone use LGPL code?


> bounces <at> lists.midnightryder.com] On Behalf Of Mick West
> I think the problem here is that LGPL is a somewhat novel form of
> contract that has little or no legal precedence.  Has there ever been
a
> lawsuit alleging violation of GPL (let alone LGPL) that been has
worked
> through to judgement in American courts?

I think the point is that GNU (i.e. RMS) want to protect free software
(because RMS himself got stiffed). The GPL license is viral so LGPL was
created to allow some commercial concessions. But the gist of it is that
it's "us vs. them" (i.e. free vs. commercial/closed software). More
flexible (commercial friendly) open source licenses generally tend to
cover copyright and warranty issues. GNU is about the free software
ideal. So, consequently there are probably going to be occasions where
(L)GPL and closed software won't sit too happily together.

I do take your point about some of the wording being confusing, but your
post seems to be of the gist that you're looking at it from the point of
view of trying to avoid having to adhere to it. You wouldn't get away
violating a contract with Sony or Microsoft, so how is this any
different? The main thing is that that you distribute the license and
source.

And from the look of this you could find yourself pursued:

	http://gpl-violations.org/

Although, if you are a free software author why should commercial
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mick West | 1 Nov 2005 01:40

Re: Anyone use LGPL code?

Nick Trout wrote:

>  
>
>>bounces <at> lists.midnightryder.com] On Behalf Of Mick West
>>I think the problem here is that LGPL is a somewhat novel form of
>>contract that has little or no legal precedence.  Has there ever been
>>    
>>
>a
>  
>
>>lawsuit alleging violation of GPL (let alone LGPL) that been has
>>    
>>
>worked
>  
>
>>through to judgement in American courts?
>>    
>>
>
>I think the point is that GNU (i.e. RMS) want to protect free software
>(because RMS himself got stiffed). The GPL license is viral so LGPL was
>created to allow some commercial concessions. But the gist of it is that
>it's "us vs. them" (i.e. free vs. commercial/closed software). More
>flexible (commercial friendly) open source licenses generally tend to
>cover copyright and warranty issues. GNU is about the free software
>ideal. So, consequently there are probably going to be occasions where
>(L)GPL and closed software won't sit too happily together.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Trout | 1 Nov 2005 01:53

Re: Anyone use LGPL code?


> someone were to spend six months developing a nice little game, it
would
> a bit of bummer to find nobody would publish it because it used a LGPL
> engine.

Does anyone know of anyone being refused a deal because of open source
(LGPL or otherwise) code? Just curious.

Nick

_______________________________________________
sweng-gamedev mailing list
sweng-gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
Permalink | Reply | 1 comment |
headers
Tom Hubina | 1 Nov 2005 14:13

Re: Anyone use LGPL code?

I know many of the contracts I've seen specifically state that you _cannot_
use GPL, LGPL, and several other Open Source variants in the product (which
may include tools depending on the project).

I remember hearing a first person account (on a list somewhere) about how
they used Open Source code/libs on a project, and couldn't get any publisher
to pick it up (I think it may have been an Open Source engine, but not 100%
sure) so they went back and started over on a clean project with zero Open
Source.

So I guess the answer is, "Yes". It's a negotiating point they will not
budge on (and for very good reason IMO).

Tom

> -----Original Message-----
> From: sweng-gamedev-bounces <at> lists.midnightryder.com
> [mailto:sweng-gamedev-bounces <at> lists.midnightryder.com]On Behalf Of Nick
> Trout
> Sent: Monday, October 31, 2005 4:54 PM
> To: sweng-gamedev <at> midnightryder.com
> Subject: Re: [Sweng-gamedev] Anyone use LGPL code?
>
>
>
> > someone were to spend six months developing a nice little game, it
> would
> > a bit of bummer to find nobody would publish it because it used a LGPL
> > engine.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Trout | 1 Nov 2005 02:40

Re: Anyone use LGPL code?


> On Behalf Of Tom Hubina
> I know many of the contracts I've seen specifically state that you
> _cannot_
> use GPL, LGPL, and several other Open Source variants in the product
> (which
> may include tools depending on the project).

Thanks Tom, interesting.

I can see how any publisher would want to avoid a GPL game. If you
release your game engine as GPL there is nothing to stop someone else
making new assets (assuming they have to because yours are copyrighted)
and selling the game themselves. All they have to do is display the GPL
and distribute source; they won't owe you a penny because the software
is free.

And the cautious extension of this is that all open source could be
problematic so why stick your neck out at all? Like I said before, I
don't even think the main issue is about the license (apart from the
above example!) it about ownership and origin.

> So I guess the answer is, "Yes". It's a negotiating point they will
not
> budge on (and for very good reason IMO).

Does your opinion differ from any of those already stated?

Nick
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Hubina | 1 Nov 2005 15:11

Re: Anyone use LGPL code?

> > So I guess the answer is, "Yes". It's a negotiating point they will
> not
> > budge on (and for very good reason IMO).
>
> Does your opinion differ from any of those already stated?

Perhaps not substantially, but to reiterate.

1. Open Source licensing issues haven't seen sufficient legal battles to
iron out any potential kinks. I know I don't want to be the first.
2. As a publisher and developer, I would want to have control over what
aspects of my software are exposed to others, and not subject to the
discretion of others (especially when the legal aspects of the language
haven't been fully tested in US courts - note, I'm talking about a
difference of opinion, not a blatant disregard).
3. Game creation has enough risks involved without throwing an uncertainty
about Open Source into the mix. Since closed source options is exist, it
makes far greater sense to go with a fixed cost up front, than an unknown
cost later.
4. Using third party tools for which there is no usable indemnification
about patent/copyright infringement inside the Open Source third party
materials is _bad_ given the current legal nonsense going on in that area.
5. I'd be especially concerned about projects that are written under a
license like LGPL, and which take contributions from folks other than the
original author. If that same project is then licensed out under a different
license (BSD for example) to get around some of the provisions in LGPL for a
specific client, and the individual contributors didn't approve such a
license change then there is the potential for them to sue and have their
contributions removed or worse.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Adams | 1 Nov 2005 12:26

Re: Anyone use LGPL code?

sweng-gamedev-bounces <at> lists.midnightryder.com wrote:
>>> So I guess the answer is, "Yes". It's a negotiating point they will
>>> not budge on (and for very good reason IMO).
>> 
>> Does your opinion differ from any of those already stated?
> 
> Perhaps not substantially, but to reiterate.
> 
> 1. Open Source licensing issues haven't seen sufficient legal battles
> to iron out any potential kinks. I know I don't want to be the first.

Although the (L)GPL hasn't been to court I understand that the FSF has
chased people for violations, and all have backed down rather than go to
court in the US.

RMS has a good legal mind, and the FSF legal man (Eben Moglen) is a lawyer.
You could ask them ! This is exactly the approach Apple took when adding
Obj-C to GCC to clarify license issues.

> 2. As a publisher and developer, I would want to have control over
> what aspects of my software are exposed to others, and not subject to
> the discretion of others (especially when the legal aspects of the
> language haven't been fully tested in US courts - note, I'm talking
> about a difference of opinion, not a blatant disregard).
> 3. Game creation has enough risks involved without throwing an
> uncertainty about Open Source into the mix. Since closed source
> options is exist, it makes far greater sense to go with a fixed cost
> up front, than an unknown cost later.
> 4. Using third party tools for which there is no usable
> indemnification about patent/copyright infringement inside the Open
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jaap Suter | 15 Nov 2005 06:13

Smokin' Fast Build

Hi,

A while back I posted a message asking what people thought of a build system 
that used a daemon listening to file-change notification events to keep the 
dependency tree up to date.

I've spend a few days hacking something quick and dirty together to test 
some ideas and I'm very optimistic that this can give substantial speed-ups. 
Doing incremental-builds without file changes using Noel Llopis' benchmark 
(I updated his generate_libraries python script to generate .sfb files) 
takes exactly zero seconds (as expected). Doing an incremental build when 
only one file has changed, or only one library has been cleaned, are also 
significantly faster.

My work-permit has just arrived meaning I start my new job tomorrow. I 
figured I'd release whatever I have, before my new contract lays claim on 
it. If somebody is interested in my incredibly crappy C# code that can't 
possibly be considered more than a hack-and-slash prototype, you can 
download it at http://www.jaapsuter.com/sfb.zip. It requires Visual Studio 
2005 to compile (you can use the free C# 2005 compiler).

Be forewarned that it's not in any usable state at the moment. It compiles 
and works for the two test projects, but that's about it. I only wrote it to 
the point where I could confirm some of my ideas; most notably that the 
file-change notification daemon makes things faster (yes), and that spawning 
different threads for different libraries speeds things up (yes). If I were 
to seriously invest time in making a build system, these are both things it 
would do again.

Most of my time was wasted with an early C++ prototype. When I finally got
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Fabian | 17 Nov 2005 00:00
Picon
Gravatar

Multi platform data driven engines

Hi guys,
I've been progressivley working on making our in-house (multi
platform) engine fully data driven. I've hit stumbling blocks along
the way, but so far have always managed to get up again and overcome
them. The latest stumbling block was how to make all the game logic of
a game into data, i first thought of using a scripting language, but
couldn't choose one. I went around and had a look at all sorts of
languages, from Lua and javascript to unreleased source scripts like
the one used in dungeon seige. I eventually decided that a scripting
language was not really the way to go, so i ventured further, thought
about "the real problem" and didn't just randomly look for scripting
languages that would fit the bill. I did come up with a solution, and
it seems very promising. Its not like any scripting language i have
seen before, in fact i wouldn't dare call it a scripting language, i'd
prefer to call it a game object event and response system. It turns
out i have created some frankenstein hybrid of a functional
programming language with a data driven schema backbone. So, nothing
really new, just not something I've personally come across before.

But, to the point:

As is always true of stuff in the computing business, anything one
person claims to have invented today, ten others can say "yeah we did
that N years ago". I wondered what kind of techniques other people had
used to empower their data driven engines. And if anyone that had also
discovered a non-script approach to driving game logic with data is
reading this thread, how did they do it, and how did it turn out in
the end with their particular technique?

Anyhoo, i thought it was about time i submitted a decent post to this
(Continue reading)

Permalink | Reply | 13 comments |

Gmane