binarycloud-dev

[binarycloud-dev] LGPL

[alex b. <en...@tu...>]

hi all,

I'm leaning heavily towards releasing all r2 code under the LGPL:

http://www.gnu.org/copyleft/lesser.html

does anyone have opinions on that?

note some stuff:
    -the r1 license header will be much smaller:
* -License    LGPL     (http://www.gnu.org/copyleft/lesser.html)

    -all contributors of _complete_ components retain copyright on those
components. (i.e. you don't get copyright for fixing a bug, :)
    -all authors who are responsible for 20% or more of a document will be
credited
    -all individual authors retain copyright on work
    -all corporations retain copyright on work.

obviously that assumes that the work is published under the LGPL under the
auspices of the binarycloud consortium.

-------

The above has a number of ramifications:
    -modifications to binarycloud core, and some user stuff, if distributed,
must be free (per lgpl)
    -BUT, unlike r1, no permission from turing is required for use, and all
of the code may be integrated into commercial products _so_long_ as proper
credit is given. the credit will be to the binarycloud consortium, not
specific organizations (to avoid the whole
original-bsd-license-credit-nightmare-list problem.)

this is a significant change, but I think it's appropriate given the
evolution of the sysem.

please, any and all comments/flames/rants/etc...

_alex

Re: [binarycloud-dev] LGPL

[Benjamin D. S. <be...@be...>]

Seems the best way to go. You want to make the application development 
environment (BC) as free as possible, but you don't want to make developers 
release the applications developed herewith released under the same 
freedom/restrictions. 

If this were straight-up GPL, I would be unable to use it. On the other hand, 
as LGPL, I could use it, develop the applications my customers need, and 
still be likely to contribute to the part that benefits you.  (the BC 
environment itself) 

IMHO, GPL-type licensing applies best to infrastructure - the specific 
application of that infrastructure to solve a specific problem is generally 
best a more proprietary license. 

-Ben 

On Wednesday 13 June 2001 21:15, you wrote:
> hi all,
>
> I'm leaning heavily towards releasing all r2 code under the LGPL:
>
> http://www.gnu.org/copyleft/lesser.html
>
> does anyone have opinions on that?
>
> note some stuff:
>     -the r1 license header will be much smaller:
> * -License    LGPL     (http://www.gnu.org/copyleft/lesser.html)
>
>     -all contributors of _complete_ components retain copyright on those
> components. (i.e. you don't get copyright for fixing a bug, :)
>     -all authors who are responsible for 20% or more of a document will be
> credited
>     -all individual authors retain copyright on work
>     -all corporations retain copyright on work.
>
> obviously that assumes that the work is published under the LGPL under the
> auspices of the binarycloud consortium.
>
> -------
>
> The above has a number of ramifications:
>     -modifications to binarycloud core, and some user stuff, if
> distributed, must be free (per lgpl)
>     -BUT, unlike r1, no permission from turing is required for use, and all
> of the code may be integrated into commercial products _so_long_ as proper
> credit is given. the credit will be to the binarycloud consortium, not
> specific organizations (to avoid the whole
> original-bsd-license-credit-nightmare-list problem.)
>
> this is a significant change, but I think it's appropriate given the
> evolution of the sysem.
>
> please, any and all comments/flames/rants/etc...
>
> _alex
>
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
"Life is short. Live it!"

Re: [binarycloud-dev] LGPL

[alex b. <en...@tu...>]

> Seems the best way to go. You want to make the application development
> environment (BC) as free as possible, but you don't want to make
developers
> release the applications developed herewith released under the same
> freedom/restrictions.

Correct. (given that I am in that business, I agree! :)

> If this were straight-up GPL, I would be unable to use it. On the other
hand,
> as LGPL, I could use it, develop the applications my customers need, and
> still be likely to contribute to the part that benefits you.  (the BC
> environment itself)

Yep. I encourage people to think of how they can generalize their
components, so we can include them in the distro. The more the better, as
far as I am concerned.

> IMHO, GPL-type licensing applies best to infrastructure - the specific
> application of that infrastructure to solve a specific problem is
generally
> best a more proprietary license.

Depends on the software, but _usually_ I agree with that statement. I think
it is reasonable to classify binarycloud as infrastructure software (that
and I have that on my company website :)

_alex

Re: [binarycloud-dev] LGPL

[Benjamin D. S. <be...@be...>]

BTW - I make extensive use of the PHPLIB libraries, and they are LGPL as 
well. 

-Ben 

On Wednesday 13 June 2001 23:27, you wrote:
> > Seems the best way to go. You want to make the application development
> > environment (BC) as free as possible, but you don't want to make
>
> developers
>
> > release the applications developed herewith released under the same
> > freedom/restrictions.
>
> Correct. (given that I am in that business, I agree! :)
>
> > If this were straight-up GPL, I would be unable to use it. On the other
>
> hand,
>
> > as LGPL, I could use it, develop the applications my customers need, and
> > still be likely to contribute to the part that benefits you.  (the BC
> > environment itself)
>
> Yep. I encourage people to think of how they can generalize their
> components, so we can include them in the distro. The more the better, as
> far as I am concerned.
>
> > IMHO, GPL-type licensing applies best to infrastructure - the specific
> > application of that infrastructure to solve a specific problem is
>
> generally
>
> > best a more proprietary license.
>
> Depends on the software, but _usually_ I agree with that statement. I think
> it is reasonable to classify binarycloud as infrastructure software (that
> and I have that on my company website :)
>
> _alex
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
"Life is short. Live it!"

Re: [binarycloud-dev] LGPL

[Alby L. <al...@th...>]

I think that sounds great, I am considering using binarycloud in a solution
and was always wondering what it meant to have permission, and whether the
permission would be revokable.


----- Original Message -----
From: "alex black" <en...@tu...>
To: "binarycloud-dev" <bin...@li...>
Sent: Thursday, June 14, 2001 12:15 AM
Subject: [binarycloud-dev] LGPL


> hi all,
>
> I'm leaning heavily towards releasing all r2 code under the LGPL:
>
> http://www.gnu.org/copyleft/lesser.html
>
> does anyone have opinions on that?
>
> note some stuff:
>     -the r1 license header will be much smaller:
> * -License    LGPL     (http://www.gnu.org/copyleft/lesser.html)
>
>     -all contributors of _complete_ components retain copyright on those
> components. (i.e. you don't get copyright for fixing a bug, :)
>     -all authors who are responsible for 20% or more of a document will be
> credited
>     -all individual authors retain copyright on work
>     -all corporations retain copyright on work.
>
> obviously that assumes that the work is published under the LGPL under the
> auspices of the binarycloud consortium.
>
> -------
>
> The above has a number of ramifications:
>     -modifications to binarycloud core, and some user stuff, if
distributed,
> must be free (per lgpl)
>     -BUT, unlike r1, no permission from turing is required for use, and
all
> of the code may be integrated into commercial products _so_long_ as proper
> credit is given. the credit will be to the binarycloud consortium, not
> specific organizations (to avoid the whole
> original-bsd-license-credit-nightmare-list problem.)
>
> this is a significant change, but I think it's appropriate given the
> evolution of the sysem.
>
> please, any and all comments/flames/rants/etc...
>
> _alex
>
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

RE: [binarycloud-dev] LGPL

[Andrew <an...@sa...>]

Alex,

We've run into problems with LGPL adoption with one of our products (iODBC).
This got so bad with larger companies eyeing it suspiciously (because its
legal language is vague as far as how it differs from the GPL, and it could
impose the same 'viral' licensing) that we finally released iODBC under a
BSD license as well.  Not that the situations are identical by any means,
but you may run into problems in the long run with bc adoption in large
companies with legal departments that find LGPL unacceptable.

Best regards,
Andrew Hill
Director of Technology Evangelism
OpenLink Software  http://www.openlinksw.com
Universal Data Access & Data Integration Technology Providers


> -----Original Message-----
> From: bin...@li...
> [mailto:bin...@li...]On Behalf Of alex
> black
> Sent: Thursday, June 14, 2001 12:15 AM
> To: binarycloud-dev
> Subject: [binarycloud-dev] LGPL
>
>
> hi all,
>
> I'm leaning heavily towards releasing all r2 code under the LGPL:
>
> http://www.gnu.org/copyleft/lesser.html
>
> does anyone have opinions on that?
>
> note some stuff:
>     -the r1 license header will be much smaller:
> * -License    LGPL     (http://www.gnu.org/copyleft/lesser.html)
>
>     -all contributors of _complete_ components retain copyright on those
> components. (i.e. you don't get copyright for fixing a bug, :)
>     -all authors who are responsible for 20% or more of a document will be
> credited
>     -all individual authors retain copyright on work
>     -all corporations retain copyright on work.
>
> obviously that assumes that the work is published under the LGPL under the
> auspices of the binarycloud consortium.
>
> -------
>
> The above has a number of ramifications:
>     -modifications to binarycloud core, and some user stuff, if
> distributed,
> must be free (per lgpl)
>     -BUT, unlike r1, no permission from turing is required for
> use, and all
> of the code may be integrated into commercial products _so_long_ as proper
> credit is given. the credit will be to the binarycloud consortium, not
> specific organizations (to avoid the whole
> original-bsd-license-credit-nightmare-list problem.)
>
> this is a significant change, but I think it's appropriate given the
> evolution of the sysem.
>
> please, any and all comments/flames/rants/etc...
>
> _alex
>
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

Re: [binarycloud-dev] LGPL

[Alex B. <en...@tu...>]

> Alex,
> 
> We've run into problems with LGPL adoption with one of our products (iODBC).
> This got so bad with larger companies eyeing it suspiciously (because its
> legal language is vague as far as how it differs from the GPL, and it could
> impose the same 'viral' licensing) that we finally released iODBC under a
> BSD license as well.  Not that the situations are identical by any means,
> but you may run into problems in the long run with bc adoption in large
> companies with legal departments that find LGPL unacceptable.

hi andrew, as always good point :)

I personally dislike BSD because it does not enforce "re-contribution" which
I think is a fundamentally good thing to force. BSD basically says
"whatever, this is free"

Can you give me a specific example of problems brought to your attention
with LGPL?

_a


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

RE: [binarycloud-dev] LGPL

[Andrew <an...@sa...>]

Alex,

Well, neither LGPL nor BSD force re-contribution if another product isn't
distributed.

The issue we found with LGPL is that an OS vendor (to remain nameless for a
little while yet) was not comfortable bundling iODBC until we changed the
license.  If you examine points 5 and 6 of the LGPL, they appear to enforce
the same viral contribution clause, and have some contradictory language as
far as what constitutes a 'derived work'.

Basically, a case could be made that everyone has to be LGPL (or GPL) with
code they write that uses bc in any way.
Now this is not so bad, but you may be restricting distribution of
commercial products built with bc.

Also, while a lot of companies are starting to use open source, there is
still a big aversion to GPL, and LGPL cannot be separated from that in
lawyers' minds due to the ambiguity in points 5 and 6.

Just my .02 - I really am not adverse to LGPL, but think it's muddy water.

Best regards,
Andrew

> -----Original Message-----
> From: bin...@li...
> [mailto:bin...@li...]On Behalf Of Alex
> Black
> Sent: Thursday, June 14, 2001 2:09 PM
> To: binarycloud-dev
> Subject: Re: [binarycloud-dev] LGPL
>
>
> > Alex,
> >
> > We've run into problems with LGPL adoption with one of our
> products (iODBC).
> > This got so bad with larger companies eyeing it suspiciously
> (because its
> > legal language is vague as far as how it differs from the GPL,
> and it could
> > impose the same 'viral' licensing) that we finally released
> iODBC under a
> > BSD license as well.  Not that the situations are identical by
> any means,
> > but you may run into problems in the long run with bc adoption in large
> > companies with legal departments that find LGPL unacceptable.
>
> hi andrew, as always good point :)
>
> I personally dislike BSD because it does not enforce
> "re-contribution" which
> I think is a fundamentally good thing to force. BSD basically says
> "whatever, this is free"
>
> Can you give me a specific example of problems brought to your attention
> with LGPL?
>
> _a
>
>
> --
> alex black, ceo
> en...@tu...
>
> the turing studio, inc.
> http://www.turingstudio.com
>
> vox+510.666.0074
> fax+510.666.0093
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

RE: [binarycloud-dev] LGPL

[Peter B. <re...@f2...>]

At 02:40 PM 6/14/01 -0400, you wrote:
>Well, neither LGPL nor BSD force re-contribution if another product isn't=
=20
>distributed.

This is the one thing that worries me about the accepted open source=20
licenses: they make it too easy not to have to contribute improvements, and=
=20
give you the ability to fork.

It is the forking part that I really don't like, and I believe it is=20
harming the community rather than helping it.  Look at Linux or PHP-Nuke=20
for an example.  If everyone had worked together on either of those=20
products rather than developing their own version, they would be much=20
further on.

For this reason I have never released my code under an open source=20
license.  In fact my code isn't licensed at all, which is worse, but I=20
haven't found a license I like and/or understand yet :-)

By all means, let people modify the code to suit their uses, but make them=
=20
distribute the modifications as patches or modules, rather than forking and=
=20
forming a new distribution called asciicloud, replicating all that already=
=20
exists in binarycloud and just changing a few small areas... and diluting=20
the programmers over two very similar projects.

<soapbox>
Recently I have come across a few PHP projects where the owner has changed=
=20
the license from GPL or similar, because people have been using the script=
=20
in ways he never intended it to be (e.g. as a module in PHP-Nuke, with the=
=20
credit removed).  I do believe in open source, but I also do not like=20
licenses which say that everything must be free, which the GPL does.

People are not all programming for nothing (as thankfully Alex seems to be=
=20
doing with Binarycloud) - I personally would like to see licenses which=20
make the product free for personal use, and cost $$ for business use,=20
become more accepted on the internet.  That way I could fund my way through=
=20
University by selling <promote> sendcard <http://www.sendcard.f2s.com>=20
</promote> :-)
</soapbox>

Just my =A300.02
Peter.


-oOo-
Maple Design - web design, hosting, domain names
http://www.mapledesign.co.uk
-oOo-

RE: [binarycloud-dev] LGPL

[John D. <jo...@we...>]

On Thu, 14 Jun 2001, Peter Bowyer wrote:

> At 02:40 PM 6/14/01 -0400, you wrote:
<<snip>>
> 
> It is the forking part that I really don't like, and I believe it is 
> harming the community rather than helping it.  Look at Linux or PHP-Nuke 
> for an example.  If everyone had worked together on either of those 
> products rather than developing their own version, they would be much 
> further on.
> 

I don't think you can paint with such a broad brush. gcc/egcs is a case where
forking resulted in a better end product. emacs/xemacs is a famous case where
the two projects continued on their seperate paths, but both have loyal user
bases, so the community was still well-served.

> For this reason I have never released my code under an open source 
> license.  In fact my code isn't licensed at all, which is worse, but I 
> haven't found a license I like and/or understand yet :-)
> 

I'm not sure anyone fully understands the licenses ;)

<<snip>>
> 
> People are not all programming for nothing (as thankfully Alex seems to be 
> doing with Binarycloud) - I personally would like to see licenses which 
> make the product free for personal use, and cost $$ for business use, 
> become more accepted on the internet.  That way I could fund my way through 
> University by selling <promote> sendcard <http://www.sendcard.f2s.com> 
> </promote> :-)
> </soapbox>
> 

Another option is (L)GPL'ing the development/bleeding-edge version, and having
a BSD-licensed version lag behind. MySQL does (or at least used to do)
something like this, although with completely opposite goals. This encourages
contribution more than a defacto dual license, especially as long as
binarycloud's feature list is rapidly growing. 

-- 

John Donagher

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD

Re: [binarycloud-dev] LGPL

[Alex B. <en...@tu...>]

> Another option is (L)GPL'ing the development/bleeding-edge version, and having
> a BSD-licensed version lag behind. MySQL does (or at least used to do)
> something like this, although with completely opposite goals. This encourages
> contribution more than a defacto dual license, especially as long as
> binarycloud's feature list is rapidly growing.

I can't see that working, i.e. people aren't interested in r1 if r2 is out
and working :)

I would prefer to settle on one, clean license that encourages and enforces
contribution in the event of redistribution, and (yes) makes credit
mandatory.

_a


--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] LGPL

[Alex B. <en...@tu...>]

> This is the one thing that worries me about the accepted open source
> licenses: they make it too easy not to have to contribute improvements, and
> give you the ability to fork.

this is why I prefer GPLish licenses. I am not interested in giving away the
code for all to use/fork/claim/etc as they please. I _am_ interested in
having a robust set of freely-usable code that carries some obigations for
use:
    -credit
    -contribution of changes if they are distributed.

> It is the forking part that I really don't like, and I believe it is
> harming the community rather than helping it.  Look at Linux or PHP-Nuke
> for an example.  If everyone had worked together on either of those
> products rather than developing their own version, they would be much
> further on.

yep.

> For this reason I have never released my code under an open source
> license.  In fact my code isn't licensed at all, which is worse, but I
> haven't found a license I like and/or understand yet :-)

I have considered making a simple license which is about as long as BSD, but
has the contribution requirement.

> By all means, let people modify the code to suit their uses, but make them
> distribute the modifications as patches or modules, rather than forking and
> forming a new distribution called asciicloud, replicating all that already
> exists in binarycloud and just changing a few small areas... and diluting
> the programmers over two very similar projects.

Exactly. Especially given that I have invested actual $ in its development.

> <soapbox>
> Recently I have come across a few PHP projects where the owner has changed
> the license from GPL or similar, because people have been using the script
> in ways he never intended it to be (e.g. as a module in PHP-Nuke, with the
> credit removed).  I do believe in open source, but I also do not like
> licenses which say that everything must be free, which the GPL does.
> 
> People are not all programming for nothing (as thankfully Alex seems to be
> doing with Binarycloud) - I personally would like to see licenses which

I'm not either. I have a business to run. I think OS code is the way to fly:
if I make this system people will use and benefit from it, and I'll get free
stuff (and so will everyone else). I think that's cool.

At the same time I am not interested in having "asciicloud" :) happen, nor
am I amenable to having binarycloud distributed as a commercial product
without credit.

> make the product free for personal use, and cost $$ for business use,
> become more accepted on the internet.  That way I could fund my way through
> University by selling <promote> sendcard <http://www.sendcard.f2s.com>
> </promote> :-)
> </soapbox>

I thought about doing something along those lines. But _even_with_ all the
forking and etc, I prefer linux and other os s/w to most proprietary
products. OS code is usually user-driven, inherently flexible, and
thoroughly tested. yes of course there is shit out there, but in general I
find os stuff to be better quality.




--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] LGPL

[Peter B. <re...@f2...>]

At 01:28 PM 6/14/01 -0700, you wrote:
> > make the product free for personal use, and cost $$ for business use,
> > become more accepted on the internet.  That way I could fund my way through
> > University by selling <promote> sendcard <http://www.sendcard.f2s.com>
> > </promote> :-)
> > </soapbox>
>
>I thought about doing something along those lines. But _even_with_ all the
>forking and etc, I prefer linux and other os s/w to most proprietary
>products. OS code is usually user-driven, inherently flexible, and
>thoroughly tested. yes of course there is shit out there, but in general I
>find os stuff to be better quality.

I wasn't suggesting that for binarycloud, just airing my views in public 
:-)  Some things should be free for all - base applications, operating 
systems etc.  I mean that the things that run on top of them - forums, 
shopping carts, code editors, shouldn't have to be free for business use - 
which seems to be the accepted view.

It is very hard to draw that line, but I hope you understand what I'm on 
about :-)
Peter.


--oOo--
Narrow Gauge on the web - photos, directory and forums!
http://www.narrow-gauge.co.uk
--oOo--
Peter's web page - Scottish narrow gauge in 009
http://members.aol.com/reywob/
--oOo--

Re: [binarycloud-dev] LGPL

[alex b. <en...@tu...>]

> I wasn't suggesting that for binarycloud, just airing my views in public
> :-)  Some things should be free for all - base applications, operating
> systems etc.  I mean that the things that run on top of them - forums,
> shopping carts, code editors, shouldn't have to be free for business use -
> which seems to be the accepted view.

Shouldn't necessarily be free, but than I consider those kinds of
applications as great candidates for free stuff. "Not free" as far as I am
concerned are installation specific requirements for security, etc. Standard
applications with little modification should be available.

> It is very hard to draw that line, but I hope you understand what I'm on
> about :-)

It is, and I don't think it should be drawn. If someone is selling a forum,
that someone else needs and they want to buy it, great!

:)

_a

Re: [binarycloud-dev] LGPL

[Alex B. <en...@tu...>]

> Alex,
> 
> Well, neither LGPL nor BSD force re-contribution if another product isn't
> distributed.

Correct. That is absolutely fine with me. You build some strange shit for
nasa that they want to keep, fine. Distribution is what's important.

They want to publish it, fine, but they have to contribute the changes they
have made to the base system back to the project.

I like that.

> The issue we found with LGPL is that an OS vendor (to remain nameless for a
> little while yet) was not comfortable bundling iODBC until we changed the
> license.  If you examine points 5 and 6 of the LGPL, they appear to enforce
> the same viral contribution clause, and have some contradictory language as
> far as what constitutes a 'derived work'.

This is true, to a certain extent, the language is a little muddled.

> Basically, a case could be made that everyone has to be LGPL (or GPL) with
> code they write that uses bc in any way.

"However, linking a "work that uses the Library" with the Library creates an
executable that is a derivative of the Library (because it contains portions
of the Library), rather than a "work that uses the library". The executable
is therefore covered by this License. Section 6 states terms for
distribution of such executables."

I think this is what you are referring to.

section 6 states:
"As an exception to the Sections above, you may also combine or link a "work
that uses the Library" with the Library to produce a work containing
portions of the Library, and distribute that work under terms of your
choice, provided that the terms permit modification of the work for the
customer's own use and reverse engineering for debugging such
modifications."

Ouch, flaw in the license.

This effectively makes commercial application vendors give away source code.
It _doesn't_ make them license it under lgpl or gpl, but the above is enough
to make most commercial people a little nervous :)

I like this:
"You must give prominent notice with each copy of the work that the Library
is used in it and that the Library and its use are covered by this License.
You must supply a copy of this License. If the work during execution
displays copyright notices, you must include the copyright notice for the
Library among them, as well as a reference directing the user to the copy of
this License."

> Now this is not so bad, but you may be restricting distribution of
> commercial products built with bc.

The distinction between "core" and "user" code is very important (and more
rigidly enforced) in r2.

Commercial distribution of binarycloud core is acceptable so long as proper
credit is given.

Commercial distribution of code in user/ is up to the copyright holder of
that code. (I.e. if you build modules within binarycloud, you retain the
copyright, and are welcome to use whatever license you desire.)

To be included in the php core of the binarycloud distro, code must be
released under the LGPL by the copyright holder, and accept that credit will
be given to the consortium (of which they would be a member)

> Also, while a lot of companies are starting to use open source, there is
> still a big aversion to GPL, and LGPL cannot be separated from that in
> lawyers' minds due to the ambiguity in points 5 and 6.
> 
> Just my .02 - I really am not adverse to LGPL, but think it's muddy water.

It's definitely more complex that "this is 100% completely free, have a nice
day" - because everyone involved needs to retain copyright and proper use of
the code they contribute. This is especially important for commercial
projects.

hey, who's up for a "BPL" (binarycloud public license) ha-ha!

:)

_a

Re: [binarycloud-dev] LGPL

[Robert W. <rob...@fr...>]

Sounds like a good idea to me.

On Thursday 14 June 2001  5:15 am, alex black wisely wrote:
> hi all,
>
> I'm leaning heavily towards releasing all r2 code under the LGPL:
>
> http://www.gnu.org/copyleft/lesser.html
>
> does anyone have opinions on that?
>
> note some stuff:
>     -the r1 license header will be much smaller:
> * -License    LGPL     (http://www.gnu.org/copyleft/lesser.html)
>
>     -all contributors of _complete_ components retain copyright on those
> components. (i.e. you don't get copyright for fixing a bug, :)
>     -all authors who are responsible for 20% or more of a document will be
> credited
>     -all individual authors retain copyright on work
>     -all corporations retain copyright on work.
>
> obviously that assumes that the work is published under the LGPL under the
> auspices of the binarycloud consortium.
>
> -------
>
> The above has a number of ramifications:
>     -modifications to binarycloud core, and some user stuff, if
> distributed, must be free (per lgpl)
>     -BUT, unlike r1, no permission from turing is required for use, and all
> of the code may be integrated into commercial products _so_long_ as proper
> credit is given. the credit will be to the binarycloud consortium, not
> specific organizations (to avoid the whole
> original-bsd-license-credit-nightmare-list problem.)
>
> this is a significant change, but I think it's appropriate given the
> evolution of the sysem.
>
> please, any and all comments/flames/rants/etc...
>
> _alex
>
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev