On Fri, 14 Oct 2005 15:58:22 +0900 Carsten writes:
> On Fri, 14 Oct 2005 16:07:33 +1000 Dan <[EMAIL PROTECTED]>
> babbled:
>
> > It's Friday, and I'm not doing any more coding, so I'll weigh in
> on this
> > one :)
> >
> > I was somewhat surprised when I realised that all Enlightenment
> stuff is
> > BSD.
> >
> > The GPL license offers protection from predatory bodies - mainly
> > corporations - from taking your code and building on it without
> giving
> > those changes back. This seems like a good protection to me. The
> > consensus here seems to be that the BSD license gives them the
> most
> > freedom. That may be so, but it also offers no protection. Say for
>
> > example Microsoft or Apple or some other company come along and
> lift
> > your code, incorporating it in their next product, but adding a
> couple
> > of thousand hours of work to it. They of course don't give
> anything back
> > to the original authors. Wouldn't that worry people? Perhaps it
> would
> > never happen, but then again perhaps it would.
> >
> > The 'freedom' arguement also ignores the fact that people can
> > dual-license their code. Why not negotiate a dual-license deal
> with
> > developers so that the code that is released to the public is GPL,
> but
> > the developers get offered a BSD-licensed copy?
> >
> > Not being an Enlightenment developer at the moment ( Perl's the
> limit
> > ... whatever happened to those Perl bindings, by the way ), I'm
> not
> > particularly bothered either way. I suppose I'm more curious. Of
> course
> > I respect the developers' choice to put whatever license they want
> on
> > their code, but I'd like to hear more from people who have the
> time to
> > respond why they see the BSD is better for them than the GPL -
> > especially when there are options like dual-licensing.
>
> OK. I guess this topic has done the rounds years ago and time is for
> a new one.
> i emphasise that this is a PERSONAL OPINION base on experience,
> knowledge of
> industry, technical facts, and all the licenses in question as well
> as others
> out there.
>
> fact: once source is available it IS able to be stolen. the chances
> of being
> able to lift large chunks of useful code (eg take the image scaling
> routines or
> the alpha blending routines) which is where a lot of the really
> tight code is,
> is tirival. no one would ever know. reformat it a bit and that's it.
> there is
> very little you can do. you will never know its stolen. its part of
> a much
> larger codebase that suddenly is faster and nicer. we have not the
> resources to
> litigate nor the time to scour the world looking for code and
> products that may
> have possible used the code, disasembling their machnie code and
> hunting for
> patterns that might possibly indicate our code (and a bit of
> reformatting - if
> u loop one way or another) can even make this entirely pointless.
> theft is
> trivial. not getting caught is easy as pie. accept it. even if they
> dont steal
> the code - they can READ it and find the IDEAs and HOW to do it then
> re-implement (alomsot identically). this doesnt violate even the
> gpl.
>
> now in an attempt to have an olive branch stretched out to the world
> that
> doesnt eat, sleep, breathe open source, we are making the barrier of
> entry
> lower but not REQUIRING they ship source. they have other options.
> shipping
> source is one way of meeting attribution clauses. others are to
> advertise or to
> simply tell the develoeprs about the use of it. as a matter of FACT
> that if
> they take code and dont give back - they bear the burdern of
> maintenance and
> handling a fork. they will find it hard to incorproate new
> improvements and
> eventually due to practical concernns will be driven back to the
> main tree and
> realise it is better for them to give back what they do - if
> anything, and save
> costs.
>
> also note - a lot of things are LIBRARIES - they mostly will not
> GIVE BACK as
> they build ontop of an api. their IP is in their app, not the lib.
> if they find
> a bug - it helps them to submit a patch as that patch is then in
> upstream and
> they dont have to maintain a fork. they can concentrate on their own
> product
> and not worry about a slew of libraries etc. they are using the api
> of. they
> have much fewer license concerns.
>
> for the "open soruce world" the lbiraries are as open - if not more
> so, than
> most, so nothing lost there.
>
> and finally - i went with this license because frankly - i accepted
> long long
> long ago that peolpe will take and NOT GIVE BACK. they do it with
> gpl - and
> they do it in terms of download then ask for support - and support
> takes time.
> time costs money. thus effectively they are taking and NOT giving
> back. they
> will never write a single patch or a line of code. they will use it
> and ask for
> support/help - EVEN IF the help is IN documentation - they dont read
> it. they
> prefer to write an email to a developer and get a personalised
> response. dont
> worry about licenes - this is the WORST problem with open source. by
> FAR.
> companies are unlikely to just "steal". thats the view of those that
> hate
> anything commercial. practicality is that the companies need some
> support -
> will ask a bit, realise they use up your time and offer to PAY you
> for it and
> PAY for patches, custom code ans support BECAUSE the license is
> muchmore open.
> this helps you get some minimal money for your hard work - better
> than $0. note
> - we dont get paid ANYTHING to produce E related code. it's produced
> out of
> sheer love, sweat and tears. for all the students out there - this
> stuff is
> done in time on evenings and weekends after exhausting days of work.
> year in
> and year out. for peolpe with jobs personal time is precous and
> worth a lot to
> them personally - so in working on e we invest much of ourselves in
> it. we are
> a project with $0 funding. unlike many other projects of similar
> visibility, no
> company has stepped forward to seriously partner with us to fund its
> development (thus it moves very slowly). over the years there have
> been times
> when me, or mandrake or mej have had paid work time to work on
> things. but
> those have been minimal in the scheme/lifetime of E.
>
> a BSD +attribution license is a way of extending an olive branch to
> companies
> possibly willing to put down some hard cash. we all have principles
> and stick
> to them like glue. i have had a few job offers before for large
> sums, BUT they
> would have meant an IP agreement that would mean i no longer could
> work on E as
> all my coding work would belong to the company. such offers i have
> turned down,
> even after negotiations and big carrots. if you cant, trust us that
> we have the
> interests of the project at heart and will maintain that, but in
> doing so we
> like to "bend with the wind" a bit more than most to achieve the
> goal.
>
> so... after a bit of length there - thats the reason i have used bsd
> licenses,
> and almost all of the core develoeprs agree with such licenses as
> being the way
> to go - we may simply think alike on the topic, but that is one
> thing that
> definitely binds us all together.
>
All of this appears reasonable, and yet there are arguments that
are also reasonable to the effect that license XYZ is instead a 'better'
way to go.
Rather than agonize over attempting to dissect the fine points of
license A over license B, one can offer the option of both (if possible)
as has been suggested by the poster.
In particular, if BSD and LGPL are the A and B here, then why not
have all "e" code covered under a choice of either - ie. a company or
a distribution can use BSD or LGPL as they wish. Where is there a loss to
e, or its developers, in this added extra flexibility??
Furthermore, in an attempt to better understand the possible benefits
of A over B, or A and/or B, offerings.. one might want to look around and
see which projects that use any such, and how they've fared.
If one does this, one would tend to incline to the conclusion that
those projects that use LGPL are more numerous, and have been somewhat
more
successful in being "adopted" than those that use BSD.
For LGPL/GPL one has: the Linux kernel, all the basic GNU libs/programs,
GNOME/Gtk, KDE/Qt, and a host of others...
For BSD one has: the various BSD kernels, the X.org implementation
of X11, enlightenment, and some others...?
On Fri, 14 Oct 2005 04:15:57 -0400 Michael writes:
> On Friday, 14 October 2005, at 01:17:02 (-0400),
> Jose O Gonzalez wrote:
>
> > I personally do not care much for any licensing schemes, and every
> > piece of code I've ever put up here, meager as it's been, I've done
> > so with no conditions whatever ......
>
> Anything you write is copyrighted. Whether or not you implicitly
> assign copyright to the original author(s) when you submit a patch
> or
> block of code is a matter of much debate.
>
Not so. This very much depends on particular countries and their
laws. In the USA, while one is indeed the 'author' of whatever one
writes,
one needs to expressely claim copyright ownership, or one may not have
the legal right to such after it is posted somewhere.
> > But villifying one license scheme as 'political' and blessing
> > another as the one true 'apolitical' choice, is quite flawed.
>
> The GPL is designed around the political views of GNU and RMS. The
> BSD license basically says, "We don't care what you do with this as
> long as you give us credit." The only thing that's more free than
> that is "public domain." So as licenses go, BSD is pretty much as
> apolitical as you can get.
>
Ummm... As I've stated, I have little care, personally, for any
licensing scheme.. But looking over this whole thread, I'd put this
forward:
If 'apolitical-ness' is what e is after, then public
domain would be best.
If thwarting the political views of RMS, then anything *but*
LGPL/GPL would be best.
If instead e seeks support/acceptance/funding etc. from companies
or whatnot, then if we look at the results mentioned above... it would
seem that furthering the political views of GNU and RMS has served
a very large number of projects *very* well.
Perhaps e needs to rexamine, in a realistic "non-religious" manner,
what its priorities are.. and make a serious study of what has worked
best for projects, and what has not.
Jose.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
