nanogui: Thread: Re: Stupid licensing thread (Was: Request for comments - Microwindows)

On 4 Oct 1999, Vidar Hokstad wrote:

> >I still personally think the MPL is the only standard license that fits 
> >the linked in case at all 
> 
> I agree, but on the other hand I'd gladly support licensing the code under
> both the GPL and the MPL, so that those who wants to develop free software
> can do so and still use other GPL'd software in their programs.

IMHO, the simple/obvious answer is GPL.  If someone wants to write
commercial/closedsource programs, there's nothing at all stopping them
from writing their own library, under their own license.  I very much
dislike the thought of someone making money off any code I've written,
without giving something back to the opensource community, and I'm sure
quite a few people would agree.

As long as the API and/or messaging protocol are open spec, then anyone
can write their own library.  X is an example, XFree uses opensource
license, metrox and accelx used closed.  Same function, same result, but
they had to write their own library.

Davey

On Tue, 5 Oct 1999 06:44:43 +1000 (EST) you wrote:
>On 4 Oct 1999, Vidar Hokstad wrote: 
> 
>> >I still personally think the MPL is the only standard license that fits  
>> >the linked in case at all  
>>  
>> I agree, but on the other hand I'd gladly support licensing the code under 
>> both the GPL and the MPL, so that those who wants to develop free software 
>> can do so and still use other GPL'd software in their programs. 
> 
>IMHO, the simple/obvious answer is GPL.  If someone wants to write 
>commercial/closedsource programs, there's nothing at all stopping them 
>from writing their own library, under their own license.  I very much 
>dislike the thought of someone making money off any code I've written, 
>without giving something back to the opensource community, and I'm sure 
>quite a few people would agree. 

In our case, our alternative is to write our own library, yes, or choose
one under a less restrictive license. Currently I work part time on a widget
set for NanoGUI. In the near future I and another developer will be working
nearly full time on it, and we also sponsor another company to port a major
software product to NanoGUI.

This is code that we contribute back. If the _contributors_ to NanoGUI
regards prefer a restrictive licensing scheme over those contributions,
then fine. In that case we'll spend our time and money improving
another product instead, or license a closed source product instead of
spending or time and money on supporting an open source project.
 
>As long as the API and/or messaging protocol are open spec, then anyone 
>can write their own library.  X is an example, XFree uses opensource 
>license, metrox and accelx used closed.  Same function, same result, but 
>they had to write their own library. 

Actually they wouldn't have had to if they didn't want to. The XFree license
permits closed source use.

Vidar Hokstad

> >As long as the API and/or messaging protocol are open spec, then anyone 
> >can write their own library.  X is an example, XFree uses opensource 
> >license, metrox and accelx used closed.  Same function, same result, but 
> >they had to write their own library. 

[Equally a server]

> Actually they wouldn't have had to if they didn't want to. The XFree license
> permits closed source use.

Indeed. And while LGPL might be better in some ways than the BSD license X
wouldnt be where it is today had it had a GPL library

I totally agree with Alan...

------------------------------------------------------------------
"It's not about the money...It's about the rules.  Without rules,
   we might as well be tree climbers flinging crap at each other."
                          - Red Foreman of That '70s Show

On Mon, 4 Oct 1999, Alan Cox wrote:

> > >As long as the API and/or messaging protocol are open spec, then anyone 
> > >can write their own library.  X is an example, XFree uses opensource 
> > >license, metrox and accelx used closed.  Same function, same result, but 
> > >they had to write their own library. 
> 
> [Equally a server]
> 
> > Actually they wouldn't have had to if they didn't want to. The XFree license
> > permits closed source use.
> 
> Indeed. And while LGPL might be better in some ways than the BSD license X
> wouldnt be where it is today had it had a GPL library
> 
> 

On Monday, October 04, 1999 4:51 PM, Vidar Hokstad ####@####.#### wrote:
:  the near future I and another developer will be working
: nearly full time on it, and we also sponsor another company to port a major
: software product to NanoGUI.
: 
: This is code that we contribute back.

	Correct me if I'm wrong: If we license LGPL _or_ MPL, 
it is not required to contribute any code back.


 If the _contributors_ to NanoGUI
: regards prefer a restrictive licensing scheme over those contributions,
: then fine. In that case we'll spend our time and money improving
: another product instead, or license a closed source product instead of
: spending or time and money on supporting an open source project.

	So we need a license that:
		1) must
	or	2) should
		cause contributors to contribute code back.  Which?

On Mon, 4 Oct 1999 18:28:03 -0600 you wrote:
>On Monday, October 04, 1999 4:51 PM, Vidar Hokstad ####@####.#### 
>wrote: 
>:  the near future I and another developer will be working 
>: nearly full time on it, and we also sponsor another company to port a major 
>: software product to NanoGUI. 
>:  
>: This is code that we contribute back. 
> 
> 
>Correct me if I'm wrong: If we license LGPL _or_ MPL,  
>it is not required to contribute any code back. 

Depends on how the code is organized - with MPL you still have to
contribute back changes to the existing code, but it is easier to
add proprietary code outside the existing code.

We will contribute back no matter what license - if we'd been afraid
of releasing code we wouldn't have considered NanoGUI in the first
place. My concern is being able to use proprietary code for which we
have no control over the license terms, and were we in some cases
may explicitly not be allowed to release anything but stripped binaries.

In our case we won't link directly to the server, though, so as long
as the client library has a liberal enough license (such as the MPL),
that's enough for us.

> If the _contributors_ to NanoGUI 
>: regards prefer a restrictive licensing scheme over those contributions, 
>: then fine. In that case we'll spend our time and money improving 
>: another product instead, or license a closed source product instead of 
>: spending or time and money on supporting an open source project. 
> 
> 
>So we need a license that: 
> 
>1) must 
> 
>or 
>2) should 
> 
>cause contributors to contribute code back.  Which? 

For the server side I don't really have a preference. I know that _we_
(as in Screen Media) can live with pretty much any open source license
on the server without problem, including the GPL. I'm concerned about
what others would want for it too, though. For the client library I
would certainly prefer a much more liberal license. But since all the
logic will be on the server side anyway, I can't see the point with a
restrictive license for the client library.

But as we've been through before: Many people might prefer to link directly
with the server (doesn't apply to us), for instance when running on systems
without networking support. And the more restrictive license on the server,
the fewer of that kinds of projects will be able to use NanoGUI. For that
reason I'd prefer a not too restrictive license for the server side too,
because it might help with developer mindshare.

Regards,
Vidar

Hi,
I think this remark is stupid!
Of course we don't want that the code we wrote is used by commercial
companies, but don't you think that those companies can make great steps in
free software?

Example:
Do you think Linux would be what it is today if RedHat, SuSe, Caldera,
etc... don't make money on it. And don't forget that RedHat for example use
ONLY free software!

If we think like you think : "... those companies can write their own
library...", the work of these companies is just loosed for open-source
software. If we think that those companies that have people working
full-time on open-source software can add value to open-source software and
help our work in this area, it will be a good thing.
But that don't means that those companies must release all their work under
open-source. Think of Oracle, Sybase, etc... porting their DB to Linux. They
use the work of the glibc coders, the kernel coders, etc... but don't
release their source-code. Nobody is complaining about that.

That's the reason why the LGPL, MPL licenses were created. And we MUST use
it where it's possible to use it. Don't forget too, that KDE and GNOME is
developped by some people that are paid by commercial companies to work full
time on it. It won't be possible if those companies don't make money on
open-source software.

Hope this will change your opinion on this license thread.
Bye
-jec


-----Original Message-----
From: Vidar Hokstad ####@####.####
Sent: Tuesday, October 05, 1999 12:51 AM
To: David Murn
Cc: ####@####.#### ####@####.####
Subject: Re: Stupid licensing thread (Was: Request for comments -
Microwindows)


On Tue, 5 Oct 1999 06:44:43 +1000 (EST) you wrote:
>On 4 Oct 1999, Vidar Hokstad wrote: 
> 
>> >I still personally think the MPL is the only standard license that fits

>> >the linked in case at all  
>>  
>> I agree, but on the other hand I'd gladly support licensing the code
under 
>> both the GPL and the MPL, so that those who wants to develop free
software 
>> can do so and still use other GPL'd software in their programs. 
> 
>IMHO, the simple/obvious answer is GPL.  If someone wants to write 
>commercial/closedsource programs, there's nothing at all stopping them 
>from writing their own library, under their own license.  I very much 
>dislike the thought of someone making money off any code I've written, 
>without giving something back to the opensource community, and I'm sure 
>quite a few people would agree. 

In our case, our alternative is to write our own library, yes, or choose
one under a less restrictive license. Currently I work part time on a widget
set for NanoGUI. In the near future I and another developer will be working
nearly full time on it, and we also sponsor another company to port a major
software product to NanoGUI.

This is code that we contribute back. If the _contributors_ to NanoGUI
regards prefer a restrictive licensing scheme over those contributions,
then fine. In that case we'll spend our time and money improving
another product instead, or license a closed source product instead of
spending or time and money on supporting an open source project.
 
>As long as the API and/or messaging protocol are open spec, then anyone 
>can write their own library.  X is an example, XFree uses opensource 
>license, metrox and accelx used closed.  Same function, same result, but 
>they had to write their own library. 

Actually they wouldn't have had to if they didn't want to. The XFree license
permits closed source use.

Vidar Hokstad

---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####

On Tue, 5 Oct 1999 09:16:44 +0200  you wrote:
> 
>Hi, 
>I think this remark is stupid! 
>Of course we don't want that the code we wrote is used by commercial 
>companies,

For some, that holds true. For me the only reason I have the time to
work on NanoGUI and NanoWidgets is because I'm _paid to do so_,
because the company I work for see the benefits of supporting open
source where we can.

>but don't you think that those companies can make great steps in 
>free software? 

Of course I do. I'm paid to do development on free software. I wouldn't
even be in this job if I hadn't been promised from the start that we
would contribute code back.

>Example: 
>Do you think Linux would be what it is today if RedHat, SuSe, Caldera, 
>etc... don't make money on it. And don't forget that RedHat for example use 
>ONLY free software! 
> 
>If we think like you think : "... those companies can write their own 
>library...", the work of these companies is just loosed for open-source 
>software.

I agree, and if you reread my message, you might see that I made that
remark to show people that choosing a restrictive license will have a
very real effect on what people are willing to contribute. We (Screen
Media) _can't_ spend lots of time contributing to a project if the
license is too restrictive for the project to be of any use for us. 

But for us the real result of a too restrictive license would be that
we would _have_ to write our own library, or find a less restrictive open
source project to contribute to.

>If we think that those companies that have people working 
>full-time on open-source software can add value to open-source software and 
>help our work in this area, it will be a good thing. 
>But that don't means that those companies must release all their work under 
>open-source. Think of Oracle, Sybase, etc... porting their DB to Linux. They 
>use the work of the glibc coders, the kernel coders, etc... but don't 
>release their source-code. Nobody is complaining about that. 
> 
>That's the reason why the LGPL, MPL licenses were created. And we MUST use 
>it where it's possible to use it. Don't forget too, that KDE and GNOME is 
>developped by some people that are paid by commercial companies to work full 
>time on it. It won't be possible if those companies don't make money on 
>open-source software. 

I mostly agree. I think the LGPL and GPL is fine for _most_ software.
Where I think they are too restrictive is for important parts of our
"infrastructure": system libraries, code that we _want_ everyone to use
because we want it to become standard. If NanoGUI shall have any chance
of becoming pervasive in the embedded/small systems market, then it need
a license that means that embedded and small systems developers _can_
use it.

And this market is a bit special, because it is a market so extremely
dependent on size. By going with a commercial browser instead of an
open source one (Mozilla), and paying both porting costs (to port it
to NanoGUI) and license costs, we save a lot of money because the
commercial browser is small enough that our hardware costs go down
enough to _more_ than cover the licensing costs.

For high volume, low margin markets, cost cutting like that is essential
to survival. If we want our company to survive, we _can't_ choose a
program that means we will have to add 8MB more flash, like we'd likely
have had to do with Mozilla (and for the record, the company we're
cooperating on with the browser has been very reasonable about licensing
issues compared to some of our other partners), just to go with an open
source product.

I'd rather use Mozilla, if it was economically feasible for us, because
I see tremendous benefits in having full access to the source, and being
able to do modifications (and contribute them back to the main tree).

But open source doesn't work for everyone and in all cases, and if the
goal is for NanoGUI to be "X for small systems", then we need be pragmatic
about making it possible for everyone to use it.

Regards,
Vidar Hokstad

I sent this message one hour ago but was misinterpreted. The destinator is
David, not Vidar.
Do please reread it with this in mind.
Thanks
-jec

Message:
Hi,
I think this remark is stupid!
Of course we don't want that the code we wrote is used by commercial
companies, but don't you think that those companies can make great steps in
free software?

Example:
Do you think Linux would be what it is today if RedHat, SuSe, Caldera,
etc... don't make money on it. And don't forget that RedHat for example use
ONLY free software!

If we think like you think : "... those companies can write their own
library...", the work of these companies is just loosed for open-source
software. If we think that those companies that have people working
full-time on open-source software can add value to open-source software and
help our work in this area, it will be a good thing.
But that don't means that those companies must release all their work under
open-source. Think of Oracle, Sybase, etc... porting their DB to Linux. They
use the work of the glibc coders, the kernel coders, etc... but don't
release their source-code. Nobody is complaining about that.

That's the reason why the LGPL, MPL licenses were created. And we MUST use
it where it's possible to use it. Don't forget too, that KDE and GNOME is
developped by some people that are paid by commercial companies to work full
time on it. It won't be possible if those companies don't make money on
open-source software.

Hope this will change your opinion on this license thread.
Bye
-jec


-----Original Message-----
From: Vidar Hokstad ####@####.####
Sent: Tuesday, October 05, 1999 12:51 AM
To: David Murn
Cc: ####@####.#### ####@####.####
Subject: Re: Stupid licensing thread (Was: Request for comments -
Microwindows)


On Tue, 5 Oct 1999 06:44:43 +1000 (EST) you wrote:
>On 4 Oct 1999, Vidar Hokstad wrote: 
> 
>> >I still personally think the MPL is the only standard license that fits

>> >the linked in case at all  
>>  
>> I agree, but on the other hand I'd gladly support licensing the code
under 
>> both the GPL and the MPL, so that those who wants to develop free
software 
>> can do so and still use other GPL'd software in their programs. 
> 
>IMHO, the simple/obvious answer is GPL.  If someone wants to write 
>commercial/closedsource programs, there's nothing at all stopping them 
>from writing their own library, under their own license.  I very much 
>dislike the thought of someone making money off any code I've written, 
>without giving something back to the opensource community, and I'm sure 
>quite a few people would agree. 

In our case, our alternative is to write our own library, yes, or choose
one under a less restrictive license. Currently I work part time on a widget
set for NanoGUI. In the near future I and another developer will be working
nearly full time on it, and we also sponsor another company to port a major
software product to NanoGUI.

This is code that we contribute back. If the _contributors_ to NanoGUI
regards prefer a restrictive licensing scheme over those contributions,
then fine. In that case we'll spend our time and money improving
another product instead, or license a closed source product instead of
spending or time and money on supporting an open source project.
 
>As long as the API and/or messaging protocol are open spec, then anyone 
>can write their own library.  X is an example, XFree uses opensource 
>license, metrox and accelx used closed.  Same function, same result, but 
>they had to write their own library. 

Actually they wouldn't have had to if they didn't want to. The XFree license
permits closed source use.

Vidar Hokstad

---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####