ShiftSpace and Open Source Licensing
Mushon | Shual.com
Hi friends,
a discussion on the list have made ShiftSpace open source licensing issue come up.
To quote Johan:
"...I believe the best start is to decide on and communicate some license for the shiftspace (client side) code, so others can decide whether it's a thanks-but-no-thanks kind of contribution or a neat, risk free piece of beautiful architecture to suck into the system. This is at least the reason why I haven't done anything like that myself yet, which I would otherwise be likely to do..."
So we have a couple of licensing models to start with: GPL, MIT, MPL, BSD and GNU LGP were mentioned, but we want to know what would make you as a developer most inclined to contribute code to the project. Personally we're pretty open to your input and most of all would like to see you aboard.
Johan started to pitch for a MIT/MPL/BSD direction:
"...it always feels a bit safer hacking something you know is MIT-, MPL-, BSD- et cetera licensed, if you invest any time in it. You do write nice code, so it's rather tempting to play around with."
Dan Said:
"...I've been working on the assumption we're going with GPL, but I'm open to input. Personally I like that GPL has a viral aspect to it, but I also understand that infringes on important freedoms for how the code can be used..."
This might open a
discussion about the licensing for the content made using ShiftSpace
(the shifts) should we go for a default Creative Commons license?
Copy-Left? Copyright? I would be interested in what you think of
licensing the design as well, the logo? the interface?
In general, we want to
be open, but how?
What do you think?
--
| Mushon
Zer-Aviv Shual design studio NY www.Shual.com / 1-646-283-6057 |
 |
Johan Sundström
On 11/17/06, Mushon | Shual.com <Mus...@shual.com> wrote:
> Johan started to pitch for a MIT/MPL/BSD direction:
>
> "...it always feels a bit safer hacking something you know is MIT-,
> MPL-, BSD- et cetera licensed, if you invest any time in it. You do
> write nice code, so it's rather tempting to play around with."
>
> Dan Said:
>
> "...I've been working on the assumption we're going with GPL,
> but I'm open to input. Personally I like that GPL has a viral aspect
> to it, but I also understand that infringes on important freedoms
> for how the code can be used..."
There is actually no particular conflict *necessary* between these
licenses; many projects rightly dual- or triple-license their code,
and for good reason too. I'm a core committer of the programming
language Pike, which is one example, being GPL, LGPL and MPL. The idea
being that adopters may opt to think of and use the project as either
one (or any subset thereof) -- making derivative versions according to
GPL, or MPL, should they want to, for instance, without being bound by
the other licenses.
The practical way of organizing things like that is not to require
committers contributing back to ShiftSpace to provide their
contributions under all of those licenses (that is however a _minimal_
requirement, to have a workable workflow), but to assign you (meaning
whichever legal entity that owns ShiftSpace today) with full rights to
their code. (Of course contributors don't resign their own copyright,
but remain at liberty to use their own code too however they want,
without risking legal action from $ShiftSpace.Owner.)
This leaves ShiftSpace with the freedom to change licenses of future
versions of the code, for instance when ThePerfectOpenSourceLicense
shows up on the scene, without chasing down every contributor ever to
attain their OK / revert and rewrite all of their code. (You do want
that freedom, trust me.)
Going with either of MIT / MPL / BSD (perhaps among others) makes your
project tempting to use, reuse, extend and base other development on,
whether commercial or not. For instance, it will grant you interest
and contributions from me, rather than my running my own similar
framework from scratch -- at least if you come to some decision
soonish rather than when I'm a month into development and already have
crafted something with similar provisions.
(It's likely I'd try integrating Hoodwink'd as a ShfitSpace layer too,
which would get you another from time to time bustling and active
community with a bunch of very skilled Ruby developers.)
> This might open a discussion about the licensing for the content
> made using ShiftSpace (the shifts) should we go for a default
> Creative Commons license? Copy-Left? Copyright?
I wouldn't go there for content made using ShiftSpace; I'd stick with
"your data is your own" to avoid losing people who don't share your
views. OTOH Metaweb's Freebase project (a meta data rich structured
take on Wikipedia, very loosely speaking) require all data contributed
to be CC licensed (don't remember which variant; CC by attribution,
most likely), so it's not without precedence.
> I would be interested in what you think of licensing the design as
> well, the logo? the interface?
No firm opinion there, but you might want to tighten your license
there, as it's what identifies *you* and the environment you host and
control, so others can't go in and steal your identity for you in the
public eye and ruin or change your reputation and public opinion about
you. The Mozilla / Firefox project might be worth peeking at, and in
particular the outcry about the Debian project's own version of
Firefox, which, with Debian's patches and changes to the codebase in
packaging was not allowed to retain the Firefox name and branding,
since the Mozilla organization did not deem it (presumably with Debian
packaging dependent bugs and misfeatures) representative of the
Firefox brand.
I'm mostly guessing about the reasons and may be wrong about all the
facts above; my own experiences are mostly coloured by how Pike in
Debian packaging has had a history of breakages not in the upstream
Pike codebase due to incomplete refactorings by the (former) Debian
package maintainer. Identity programs (loosely speaking) tighter than
the code license leave you the option of keeping face despite
unfortunate involvement from less capable or downright hostile
overtake.
You worked hard for your branding (and it looks really neat), so it's
not more than right that you (meaning whichever group holds it dear
and feels maternal to it) have more right to it than others.
All of this is of course boring legal work you could plain ignore, but
establishing ground rules is good for building community. As long as
you have attention to brevity, anyway, and go with familiar licenses
and common sense; people don't like page up and page down of legalese
thrown into their faces before they get to play with you.
> In general, we want to be open, but how?
I'd suggest doing what the Simile project at MIT does (famous for
Timeline, Exhibit, Longway and many other great open source projects
with active communities around them) and go with BSD, for instance,
for the code. I've been an active participant of Exhibit for some
time, and it's a tool and climate around it that plain rocks. :-) Much
of it can probably also be attributed to David Huynh's leadership and
skill with the crafts, but the openness default attitude helps a lot.
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
Mushon | Shual.com
Hi Johan
we just got back from
Europe and are trying to make sense of the extreme media attention the
TechCrunch review have given us.
Thanks for this rich and well articulated answer. I think the points you are making here and the experience it is based on is already an important contribution. I would like to indeed come to a decision on licensing with our current ShiftSpace inner circle and to announce it within the coming month. Your proposition of multiple licensing makes a lot of sense to me since we are actually interested in developing to be an opensource standard for metaweb application (and I mean metaweb as in apps that are consisted of meta information or manipulation of web content, not as in Metaweb.com). Being flexible with the licensing would allow companies that develop proprietary products to consider using ShiftSpace as a platform - and by that help it to further evolve as a standard (a lot of work until we get there, but it is the general direction).
For the shifts licensing we might build an interface like the one Flickr has for choosing specific license for each content item. One of the coming up features in the console will be a setting page where each user will be able to choose her defaults, licensing should go there too.
Your points concerning
keeping the visual identity 'in our hands' makes sense to me, we did
get good feedbacks on how ShiftSpace looks and on it's visual identity,
and there are indeed implications to not being consistent with it. I
researched the case of the Wikipedia
logo, I guess that even in this case they did maintain centralized
control of what will be the face of Wikipedia and decided to decide
through a competition. I believe that if the current design would be
rivaled by users who believe it should change, we should then deal with
it.
We are indeed very interested in the Hoodwink'd community - these are people who 'get the metaweb' and dig Javascript. We were inspired by studying this group to think of ways ShiftSpace can maintain a group's privacy and exclusivity if such is desirable. We would love to think about it with you (another thread?).
So,
it is better late than never, but we're grateful for your feedback and looking forward to get some more interesting and constructive discussions going on on the list.
cheers,
| Mushon Zer-Aviv | |
 |
Shual.com - design studio |
 |
ShiftSpace.org - an opensource layer above any website |
|
+
|
1-646-283-6057 |
Johan Sundström
> Hi Johan
>
> we just got back from Europe and are trying to make sense of the
> extreme media attention the TechCrunch review have given us.
Cool! I'm positively surprised; let's hope it attracts users and tech
contributors alike.
> Thanks for this rich and well articulated answer. I think the points
> you are making here and the experience it is based on is already
> an important contribution. I would like to indeed come to a decision
> on licensing with our current ShiftSpace inner circle and to announce
> it within the coming month.
Good. The sooner, the better. With multi-license, you can always
broaden scope later on; in my experience you typically only get
negative community reactions for withdrawing some license (at which
point those who used your code under that license will fork their own
version of the code base from the drop-off point and say their
goodbyes).
That may be bad in itself (scattering the focus of the already scarce
resource "free external hacker attention / contributions"), but if you
are unlucky and the defectors are really bad sports, they may do their
best to drag your name in the mud and attract as much of your hacker
community as they can. The Roxen WebServer project had a particularly
nasty taste of that when the Caudium project took off from the Roxen
1.3 branch (GPL), if however for design changes and contribution
climates rather than license changes. (Ironically they a few years
later came to the same conclusions about where to strive, but by then
there were too many chasms between the projects to have much use for
one another.)
> Your proposition of multiple licensing makes a lot of sense to me
> since we are actually interested in developing to be an opensource
> standard for metaweb application (and I mean metaweb as in apps
> that are consisted of meta information or manipulation of web
> content, not as in Metaweb.com).
That is good news, and I think you technically have a fairly good
starting point too.
(Regarding metaweb.com, it would actually benefit the metaweb
community a lot if framework handling MQL -- a JSON based query
language for data interchange -- appeared on the scene and were to be
made available to the ShiftSpace platform, but it's probably still
largely proprietary, especially on the backend side, and way off in
the future.)
> Being flexible with the licensing would allow companies that develop
> proprietary products to consider using ShiftSpace as a platform - and
> by that help it to further evolve as a standard (a lot of work until we
> get there, but it is the general direction).
A potentially relevant story worth sharing is how JPEG came to such
dominance of the image format world. My perspective is of course as
skewed as anyone's, but there has not been a lack of technically
superior formats (and Microsoft is presently trying to succeed it with
one of their own), but a large factor to its success is the great JPEG
license which had an explicit goal goal of the standard being
implementable without payment of license fees.
It was good enough and safe to throw into the first browsers that
wanted embeddable graphics, and showed up in digital cameras for
similar reasons (added to, of course, by the landslide of software
interoperable with it at that time). Being good enough, early enough,
open enough and a safe card to pick up for companies operating in the
field are important factors. You have a good stab at all of the above;
it's presently the safe card aspect that is a joker leaving room for
others to sail by.
> For the shifts licensing we might build an interface like the one
> Flickr has for choosing specific license for each content item. One
> of the coming up features in the console will be a setting page
> where each user will be able to choose her defaults, licensing
> should go there too.
Sounds good. Don't rush there and keep user interfaces light. ;-)
> We are indeed very interested in the Hoodwink'd community
> - these are people who 'get the metaweb' and dig Javascript. We
> were inspired by studying this group to think of ways ShiftSpace
> can maintain a group's privacy and exclusivity if such is desirable.
> We would love to think about it with you (another thread?).
Sure; fire up threads at your leisure. :-) I'm presently taking a
cautious distanced stance, avoiding investing my hack time in
ShiftSpace until I know it's time well spent (from a point of view
that an economics or business decisions department would take). I
would probably use Hoodwink'd as a testing vehicle to try out the
ShiftSpace platform (and perhaps see what needs adding to it), once
that hurdle is cleared.
Mushon | Shual.com
Hi Johan,
I want to let you know we have given a general OK to dual licensing in our inner circle gathering last week.
Still there were a couple more questions and the research has popped a couple of questions.
- What is the meaning of dual licensing when they do not come with dual terms as well, as in, usually if there are multiple licensing, in order for you to publish under a proprietary closed license you usually have to pay (like in the case of MySQL). If there are no special requirements to not follow open source license, what is the meaning of the dual licensing?
- Quoting you:
(Of course contributors don't resign their own copyright, but remain at liberty to use their own code too however they want, without risking legal action from $ShiftSpace.Owner.)
-
It seems like you are speaking of the developers rights to their own
code, but what is stopping someone who has nothing to do with § from
coming, taking all the code and releasing it under a different name
with a closed license? In this case, what is the meaning of the more
restrictive (let's say GPL) license? One of the questions that were
asked in our meeting was if there are no restrictions (financial for
ex.) to choosing the more loose license, doesn't it render the
restrictive license as meaningless - why would anyone choose to be more
restricted if they don't have to?
- If we choose GPL/LGPL/BSD (which is where we're aiming if we go
for it), and I'm a zealot open sourcerer who will only publish his code
under GPL, will I not be discouraged to participate knowing there is
nothing stopping Microsoft from using my work through the BSD license?
If that's the case, why not just call it BSD and get it over with?
cheers,
| Mushon Zer-Aviv | |
 |
Shual.com - design studio |
 |
ShiftSpace.org - an opensource layer above any website |
|
+
|
1-646-283-6057 |
Johan Sundström wrote:
Johan Sundström
> Hi Johan,
>
> I want to let you know we have given a general OK to dual
> licensing in our inner circle gathering last week.
Cool. And before I say anything else, it's polite to point out that
IANAL; I may have been around very much license talk, but I don't have
any formal merits on the subject.
> What is the meaning of dual licensing when they do not come
> with dual terms as well, as in, usually if there are multiple
> licensing, in order for you to publish under a proprietary closed
> license you usually have to pay (like in the case of MySQL). If
> there are no special requirements to not follow open source
> license, what is the meaning of the dual licensing?
From my perspective, licensing a work under the combined restrictions
of two licenses (say GPL and BSD, for the sake of argument) is not a
dual license, but a single license of approximately complexity
squared, and most likely always self contradictory, inconsistent and
legally unenforce:able; I would generally discourage it. Such a
license sacrifices the positive familiarity factor of both components,
as the resulting license is an unknown entity, which GPL and BSD in
themselves are not.
The meaningfulness of licensing under an open source license with no
special strings attached (here presumably BSD) as well as under a free
software license such as the GPL or LGPL, are that you include larger
communities of developers in the project, that you would turn away at
the gate by offering the code under only a free software license.
You should of course not license the code under any license you do not
agree with; if MIT or BSD are too lax for your tastes, you *shouldn't*
use either, even if I'd prefer it, since it would enable me to work in
concert with you for standardizing the bones of this services ecology,
which I believe is a common sub-goal.
I'm loosely working another front to standardize user script land as
well across browsers and implementations on the level below
ShiftSpace, with the same intent of making the platform as solid,
reusable, tractable and low-threshold-to-adoption/usage as can be;
preferably better than the DOM (which is trivial for the last few
points), which is another lofty (personal) goal of my own. (As user
scripting has rapidly been approaching the state of suckiness that was
the javascript development in the late nineties' browser wars, which
was a really sorry state of affairs.)
> Quoting you:
> (Of course contributors don't resign their own copyright,
> but remain at liberty to use their own code too however they want,
> without risking legal action from $ShiftSpace.Owner.)
>
> It seems like you are speaking of the developers rights to their
> own code, but what is stopping someone who has nothing to do
> with § from coming, taking all the code and releasing it under a
> different name with a closed license?
The license terms they pick up your code under. If they adopt a BSD
code base and rerelease it as GPL, in breech of the terms of the BSD
license (I'm not sure it would be, but rereleasing GPL code as BSD
certainly would), they would be wide open targets for persecution.
> In this case, what is the meaning of the more restrictive (let's say
> GPL) license?
That free software purists that prefer their project to be bound by /
available under the GPL only, and want to make a derived work, may do
so without first requesting (and being granted) the permission to do
so from the copyright holder of ShiftSpace.
> One of the questions that were asked in our meeting was if there
> are no restrictions (financial for ex.) to choosing the more loose
> license, doesn't it render the restrictive license as meaningless -
> why would anyone choose to be more restricted if they don't have
> to?
The software development ecology is made up of lots of people of very
different alignment. Many believe in the goals of free software and
prefer the more restrictive GPL since it guarantees that their
contributions made to the present code base is free for anyone to use
under the GPL's terms, even if it does not grant all future derived
works the same status, if ShiftSpace is also BSD.
That sacrifice, from the perspective of this group, may be a decent
price to pay if it keeps the commercial players that would otherwise
invent their own incompatible ShiftSpace-esque frameworks from doing
so, when they could instead participate in ShiftSpace making that the
lingua franca or that an entire *common* ecosystem could otherwise be
built on, free world or part proprietary.
From the perspective of a company developing software that may have to
be part proprietary, the GPL is not a threat to their business model
if they be given the freedom to use the code under BSD even if
ShiftSpace would some day in the future be eaten by rabid dogs or
restricting versions from then on to GPL only, or any other nasty
event that would compromise their right of use. They might then be
forced to leave the collaborative contribution landscape where all
parties are working in concert on the same line of development and do
their own fork, but they would be no worse off than had they turned at
the gate today and implemented this framework from scratch themselves.
I hope it's clear where I'm going with this. There is a sweet spot of
collaboration and working across beliefs for common benefits, which I
find difficult to question for infrastructure projects such as
ShiftSpace or computer languages. Forks should be avoided at most
times, but the freedom to fork, and under terms that keep developers
in the loop, should be there, to keep them at the same table. When
they can no longer stay at that table, the collaborative benefits die,
but until then, and even then to the extent some parties remain at the
same table, much is gained.
> If we choose GPL/LGPL/BSD (which is where we're aiming if we
> go for it), and I'm a zealot open sourcerer who will only publish
> his code under GPL, will I not be discouraged to participate
> knowing there is nothing stopping Microsoft from using my work
> through the BSD license? If that's the case, why not just call it
> BSD and get it over with?
Well, that's of course a question you'll have to ask yourself, but I
hope you'd find an answer you would be satisfied with above. I
certainly do, anyway, but I'm both a fan of free software, open source
software, and can live with commercial players (or perhaps rather
their investors, when run by cautious old think not yet comfortable
with free software) not embracing the same core values.
> Coming to think of it all of these are in a way the same
> question, but I think we need to get it straight before we
> officially publish the license.
Yep. :-)
I'd (somewhat unrelatedly / off topic, yes) recommend the first ~75
minutes (the rest is audience questions, most rather uninteresting,
put politely) of a talk Richard Michael Stallman recently gave on
"Copyright in the age of computer networks" in Linköping,
http://shurl.org/RMS-2007-05-17 -- the audio ogg version makes a nice
podcast (and you don't really miss anything a photo of a bearded man
would add, compared to the video). It covers copyright and free
software only, but provides a good definition of free software vs open
source I'm using above.
Mushon | Shual.com
I feel like we're very close to nailing this down.
from the license page of the Greasemonkey extension:
"...Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so..."
This is as permissive as it gets (I don't think it even follows any known license, it's more like: "here, take, it's yours..."). It's not like there have been tons of developers on GM but it is a functional project (Aaron, do you have some insights on this choice of licensing?)
I could not find the license for Hoodwink'd but the main page of the repository says it's published under an MIT License, which is again very permissive maybe 'Why' or you Johan can pull some light on the choice there.
I was trying to find an example of a project that used multiple licensing, and I referred to what you, Johan mentioned:
Pike is distributed not only under the GNU GPL license, but also under the GNU LGPL and the MPL licenses.
This means that you are free to use and redistribute Pike under the conditions imposed by either license, or all, for that matter. You may thus choose to build applications of your own that heavily borrows code from Pike and license it under GNU GPL, or, if you prefer, use the code under the terms listed in the MPL license.
The way I read it, it
is a recommendation to publish the code as GPL, yet leaving an open
door for lesser licenses as LGPL and MPL.
It also seems that Firefox & Thunderbird are triple-licensed under GPL/LGPL/MPL.
What I would propose for ShiftSpace's licensing would be:
ShiftSpace is distributed not only under the GNU GPL license, but also under the GNU LGPL and the MPL licenses. (just like the Mozilla Firefox browser itself)
This means that you are free to use and redistribute ShiftSpace under the conditions imposed by either license, or all, for that matter. You may thus choose to build applications of your own that heavily borrows code from ShiftSpace and license it under GNU GPL, or, if you prefer, use the code under the terms listed in the MPL license.
With that being said, we would love for you to join us in developing ShiftSpace, writing your code on top of our platform, or contributing code back from the applications you build. We are a warm and happy family and would love to welcome you aboard.
(that means you too...)
As the lesser license
we can use MPL, BSD or MIT (though being local patriots of ITP/NYU we
will probably not want to go with the MIT license ;-) ) (+MPL rhymes with
GPL & LGPL)
let me know what you think,
offer your own wording or feel free to write a whole new one.
Unless anything dramatic happens, I think we will publish the license of choice online by Friday.
cheers (and thanks
again Johan for your insightful feedbacks),
| Mushon Zer-Aviv | |
 |
Shual.com - design studio |
 |
ShiftSpace.org - an opensource layer above any website |
|
+
|
1-646-283-6057 |
Johan Sundström wrote:
Johan Sundström
> from the license page of the Greasemonkey extension:
>
>
> This is as permissive as it gets (I don't think it even follows any known
> license, it's more like: "here, take, it's yours..."). It's not like there have
> been tons of developers on GM but it is a functional project (Aaron, do
> you have some insights on this choice of licensing?)
I would guess that is the point of it; Public Domain is IIRC rumoured
not to be valid in some portions of the world.
It is somewhat more challenging writing extensions than user scripts,
but I believe a large part of the reason GM has not had a large
committer base is that it has been difficult to enter the league until
very recently, when Aaron has worked a lot on lowering the thresholds
and making it less of an in-group vs out-group kind of dev community.
Technical provisions (subversion, Trac and wiki) have also not been
around for very long yet.
> I could not find the license for Hoodwink'd but the main page of the
> repository says it's published under an MIT License, which is again
> very permissive maybe 'Why' or you Johan can pull some light on
> the choice there.
That's my impression too. I can't speak authoritatively for the
reasoning behind it, but my gut feeling of Why the lucky stiff (and
also confirmed by his reactions to my own hacking with his code base)
is that he is an old school hacker that basically wants people to _do_
things with his code so it lives rather than dies, rotting away
untouched and unloved in a repository somewhere while the times fly
away from it. Which blends well with MIT, which goes towards making
sure the code gets used. (Another aspect or actor in the license swamp
being the rights the _code_ has, if you will.)
That's actually fairly close to my own stance too, for projects I work
on for the fun of it -- I want people to do really cool things,
standing on top of my shoulders. Make money from it, get credit for
their work, and so on, and not feel limited by red tape of mine. But
then I release much of it as PD too, and I'm not really trying to
convince anyone to take that route. (Those who do, do it because they
already feel the same way, and don't need to be convinced by
arguments.)
> I was trying to find an example of a project that used multiple
> licensing, and I referred to what you, Johan mentioned:
> "Pike is distributed not only under the GNU GPL license, but also
> under the GNU LGPL and the MPL licenses.
>
> This means that you are free to use and redistribute Pike under the
> conditions imposed by either license, or all, for that matter. You may
> thus choose to build applications of your own that heavily borrows
> code from Pike and license it under GNU GPL, or, if you prefer, use
> the code under the terms listed in the MPL license."
>
> The way I read it, it is a recommendation to publish the code as GPL,
> yet leaving an open door for lesser licenses as LGPL and MPL.
That is not how we intend it; all three licenses are equally condoned
and adopters are invited to make their own choices without any
particular recommendations or anti-recommendations from us. Not having
any particular political agenda is another way of helping people not
feel bullied or not belonging to the community due to different belief
systems or values.
(That said, and slightly off topic, the Pike community has not been
very warmly embracing; it is a very strict meritocracy in the ivory
tower meaning of the word; if you want to contribute or change things,
you should be prepared to argue rather convincingly for your plans, if
they are contrary to preferences of the core developer team, and
contributed code is held to high standards before it goes anywhere
near Pike CVS. But that is all consequences of a social climate, not
licensing.)
> It also seems that Firefox & Thunderbird are triple-licensed under
> GPL/LGPL/MPL.
Yep. It (Mozilla, back then) was the model Pike copied. GPL and LGPL,
because free software advocates like them, and Pike having had a
tradition of both since earlier still times, MPL since it allowed
commercial closed source reuse of the code, under a license saying
essentially (among other things, yes; I'm just mentioning things that
were important behind the decision) "reuse the code at will, and don't
have the audacity to blame us in court if you shoot yourself in the
foot in doing so".
I think your proposed ShiftSpace license sounds good. I would
encourage adopting a stance towards contributors that requires them to
not just license their contributions under those terms, but to
actually give ShiftSpace the code and right to distribute it as it
sees fit in the future, which (just incidentally) today means the
GPL/LGPL/MPL.
Both Pike and Greasemonkey have good ground rules like that worth
borrowing liberally from:
http://pike.ida.liu.se/development/cvs/policies.xml
http://greasemonkey.devjavu.com/projects/greasemonkey/wiki/ContributeToGreasemonkey
> As the lesser license we can use MPL, BSD or MIT (though being
> local patriots of ITP/NYU we will probably not want to go with the
> MIT license ;-) ) (+MPL rhymes with GPL & LGPL)
>
> let me know what you think,
I think it's better judging license on effect, intent and merit than
descent, but presume/hope it was more of a winking joke, as emotified.
:-)
> offer your own wording or feel free to write a whole new one.
Anyway, I'd say it's good if it has some of your personality woven
into the fabric; open source projects benefit much from a visible lead
persona behind it, bestowing it some sense of soul; Linus Torvalds
behind the Linux kernel, Aaron Boodman behind Greasemonkey, Joe Hewitt
behind Firebug, John Resig behind jQuery, and so on, at least until
the project itself has gathered enough merit to live off its own fame
alone (as all named projects incidentally have).
I wouldn't go with anything else unless it was a lot better, for some
reason you agree with. I could probably not write a better license
that conveys your vision of what you want to build and how, since I
can only guess rather coarsely at that and haven't yet worked side by
side with you on it.
> Unless anything dramatic happens, I think we will publish
> the license of choice online by Friday.
Great!
> cheers (and thanks again Johan for your insightful feedbacks),
You're most welcome.
Clay Shirky
domain" in the US and get the effect you want. The key thing here --
indeed, the only reason to have a license at all for a project like
shiftspace -- is to prevent someone from appropriating the work and
then suing people distributing free copies.
The reason multiple licenses work is that GPL is constructed so that
no GPL-only code can be made less protected from release; its a bit
like doing a code fork, albeit on meta-data instead of the code itself.
This language seems good:
> What I would propose for ShiftSpace's licensing would be:
> ShiftSpace is distributed not only under the GNU GPL license, but
> also under the GNU LGPL and the MPL licenses. (just like the
> Mozilla Firefox browser itself)
> This means that you are free to use and redistribute ShiftSpace
> under the conditions imposed by either license, or all, for that
> matter. You may thus choose to build applications of your own that
> heavily borrows code from ShiftSpace and license it under GNU GPL,
> or, if you prefer, use the code under the terms listed in the MPL
> license.
but I'd leave this out:
> With that being said, we would love for you to join us in
> developing ShiftSpace, writing your code on top of our platform, or
> contributing code back from the applications you build. We are a
> warm and happy family and would love to welcome you aboard.
The rights conversation and the community conversation are better
kept separate. Rights are conferred to individuals -- you are
conferring the right to fork, if someone wants -- but in practice, if
someone is looking at the licensing, they're already committed to the
project somehow. (I'd also leave out the warm and happy family part
in general -- if its true, you won't need to advertise it, and if its
not (and a lot of successful open source projects are not) then you
_shouldn't_ advertise it.)
-clay
Mushon | Shual.com
I must say I do agree with Clay.
We will keep the informal speak to the blog, and keep the license notice as clear as possible.
And so I think a pretty
direct copy from Pike (with the additional mention of the Firefox
license) would make sense:
ShiftSpace is distributed not only under the GNU GPL license, but also under the GNU LGPL and the MPL licenses. (just like the Mozilla Firefox browser itself) This means that you are free to use and redistribute ShiftSpace under the conditions imposed by either license, or all, for that matter. You may thus choose to build applications of your own that heavily borrows code from ShiftSpace and license it under GNU GPL, or, if you prefer, use the code under the terms listed in the MPL license.
We are also looking to install Trac (and finally leave the good for nothing Google Code)
I think, unless there are any other feedbacks on the license issue, we will install Trac, publish the license there and link to it from ShiftSpace.org
cheers,
| Mushon Zer-Aviv | |
 |
Shual.com - design studio |
 |
ShiftSpace.org - an opensource layer above any website |
|
+
|
1-646-283-6057 |
Clay Shirky wrote:
The rights conversation and the community conversation are better kept separate. Rights are conferred to individuals -- you are conferring the right to fork, if someone wants -- but in practice, if someone is looking at the licensing, they're already committed to the project somehow. (I'd also leave out the warm and happy family part in general -- if its true, you won't need to advertise it, and if its not (and a lot of successful open source projects are not) then you _shouldn't_ advertise it.) -clay --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ShiftSpace" group. To post to this group, send email to Shift...@googlegroups.com To unsubscribe from this group, send email to ShiftSpace-...@googlegroups.com For more options, visit this group at http://groups.google.com/group/ShiftSpace?hl=en -~----------~----~----~----~------~----~------~--~---
Johan Sundström
> known license, it's more like: "here, take, it's yours..."). It's not like
> there have been tons of developers on GM but it is a functional
> project (Aaron, do you have some insights on this choice of
> licensing?)
While I can't speak *for* Aaron (again assuming Boodman), here is a
talk he recently gave at Google Developer Day Sydney, stating (among
many other interesting things) why Google picked the new BSD license
for Google Gears, and most importantly to ensure that it can be ported
by anyone to as obscure and uncommon environments as possible, since
not even Google has infinite resources:
http://googlesystem.blogspot.com/2007/05/google-gears-offline-functionality-for.html
Johan Sundström
licenses, here is a much better, more credible and really well
referenced article on the subject:
http://www.dwheeler.com/essays/gpl-compatible.html
I warmly recommend reading it to any free/libre/open source software
developer for a good roundup of the subject.
Mushon | Shual.com
I will read it...
you, read this:
http://www.shiftspace.org/blog/2007/06/01/shiftspace-license
soon on a Trac near
you...
| Mushon Zer-Aviv | |
 |
Shual.com - design studio |
 |
ShiftSpace.org - an opensource layer above any website |
|
+
|
1-646-283-6057 |
Johan Sundström wrote: