|
|
| The GPL Barter Cycle - A Graphic - Updated |
 |
|
Tuesday, January 05 2010 @ 01:55 AM EST
|
In our efforts at Groklaw to explain the General Public License, or
GPL, over the years, we've used many words. But the other day I asked if anyone could think of a way to show it graphically, and PolR has done it.
That captures it, don't you think?
Some imagine that it's unthinkable to, as they view it, give away valuable IP for nothing. But, first, it's not giving it away, and second, it's not for nothing. Nor does pooling your code put you out of business.
The diagram shows a barter process. This is the key word, because such contributions of code are compensated, but the consideration is not money. It is code.
You give a little code, and you get back a lot more. When people receive back a complete Linux, they have the source code. It lets them make changes and adjustments to suit their purposes more exactly, and then they can contribute those modifications back to the project and all the contributions are then able to be integrated into the project. This ball keeps rolling, and getting bigger, and Linux keeps improving. People contribute because they want Linux to be available and to improve. There's a fairness to it, which is why it is the most popular FOSS license. And there is a purpose, to make a large body of code available that anyone can improve and enjoy. People build businesses around Linux. Google did. Amazon too. It's great for startups, as Mark Shuttleworth has explained. He built a profitable business, Thawte, using FOSS code. He was asked in an interview about the impact of FOSS:
Jeremy Jones: What impact will free and open source software have on the world?
Mark Shuttleworth: Perhaps a better way to look at this is that free software itself is just one manifestation of a broader change that is happening in the world. 10 years ago we were all extremely excited about connecting the world. And while that job isn't yet done, there are still billions of people who don't have running water or electricity, let alone access to the Internet. But it's clear that we're on a trajectory now to get the whole world connected to the Internet, whether that takes 10 years or 50 years is a matter of social policy and conscience. But we are on that trajectory.
What's happening now, a decade later, is that we're figuring out completely new ways to create work, powered by the Internet. And what we're finding is that it's possible to very efficiently, very effectively, gather together the best thinkers, or the best producers, or the best creators in a particular field and empower them to create something that everybody benefits from. This is clearly true in the field of software, where free software has captured that ideal and that process....
And so us free software guys can be proud of, in one sense, being the first to capture the possibilities of global collaboration around a shared digital commons. But we shouldn't overstate our contribution, that we are ourselves part of a much bigger movement. And over the next few years, I believe that will become increasingly clear. And smart companies, smart individuals will figure out how to make the most of that. All of this may help one to comprehend why
Ransom Love, formerly CEO of Caldera before Darl McBride, said he wanted to Open Source Unix and merge it with Linux:
"When we acquired SCO and Unix, our intention was to see how Unix could expand and extend Linux. In a lot of technologies, Linux was going in slightly different ways, but we thought Unix was the natural companion to it.
"We took the Linux code that was available and learned to cleanly match it with the Unix APIs. The idea was to adopt Linux APIs and mechanisms to function on top of a scalable Unix code designed for SMP [symmetric multiprocessing]. At the time, Linux was moving to clustering to make Linux more scalable. We wanted to combine Unix's improved symmetric multiprocessing with Linux so that it would have both excellent clustering and SMP," he continued.
"Indeed, at first we wanted to open-source all of Unix's code, but we quickly found that even though we owned it, it was, and still is, full of other companies' copyrights," Love added. Hopefully this will explain why Caldera, now SCO Group, would enter into contracts that involved pooling IP with partners. And it also explains rather simply how high end code ended up in UnitedLinux and Linux, period, don't you think? But how to explain SCO then turning around and suing because SMP and other high end functionality was in Linux? That is the puzzlement. So what happened? Why wasn't UNIX completely open sourced? Love explained in this longer interview in 2003 by Steven J. Vaughan-Nichols:
Love: The challenge was that there were a lot of business entities that didn't want this to happen. Intel [Corp.] was the biggest opposition.
Vaughan-Nichols: Intel? Why?
Love: I don't know their real reason, but my sense was that they were using Linux against Unix and Sun [Microsystems Inc.]. They wanted to destroy the Unix base on Intel in favor of Linux so Sun wouldn't have a low-end Unix path.
And, of course, there was their love-hate relationship with Microsoft. At the same time, they didn't want to displace Microsoft with a Linux that had the best of both operating systems.
Linux and Unix are highly compatible and should be supportive of each other, but they were being pitted against each other because no one wants to threaten Microsoft. In Intel's case, Windows was also making them too much money.
We didn't want to spend years clearing out the old copyright issues in the face of corporate opposition. So, instead we worked on Linux Kernel Personalities to bring Linux application compatibility to SCO Unix (formerly UnixWare) and OpenServer. The idea was to enable developers to write for both Unix and Linux with a common Application Programming Interface (API) and common Application Binary Interface (ABI). That way developers didn't have to work so hard, and Unix users, the client base we inherited from SCO, could run Linux applications.
We were no longer thinking about mixing code; we were trying to create a common development environment. We were trying to keep the Unix and Linux kernels separate, while tying them to common APIs and ABIs.
And yet SCO, under new management, turned around and threatened Linux end users regarding ABIs. Imagine the world's surprise. How can one explain SCO sending a letter [PDF] to Linux end users in December of 2003 saying that "...the UNIX ABI Code has only been made available under copyright restrictions" and was made available for development for Unix and not for Linux under the GPL. So, which CEO was telling the truth? I direct you to the previous article for some indications.
Hopefully, this graphic will help people to understand the GPL better.
There may be other aspects of the way the GPL works that you can express graphically. If so, let us know. PO1R
took the penguin image, Tux, from Larry Ewing's site. Ewing lets us use Tux with the following terms:
Permission to use and/or modify this image is granted provided you acknowledge me lewing@isc.tamu.edu and The GIMP if someone asks.
And PolR says you can use his image under the same terms.
Update: Greg Kroah-Hartman describes it beautifully in this interview with LinuxUser:
*What would you say you’ve learned from being a Linux kernel maintainer?
*I think the best thing I’ve learned over the years is humility. There is always someone out there that is better than you and can point out problems in your code. And that’s good, because in the end what matters most is the code getting better, and by virtue of that, Linux getting better. The old phrase is, “There’s always someone smarter than you, and they work for someone else” when it comes to employees at a company. But with Linux, it doesn’t matter what company someone works for, they all contribute to the kernel as a shared goal of making it better. And by the individuals making things better, everyone overall gets something that is better as well. I think it is absolutly amazing to see how far Linux has come in the short time it has been around. It now powers over 80% of the world’s top supercomputers, as well as powering the most common cell phone for 2008, with the exact same codebase. That’s an engineering goal that no one has ever achieved, and one that no one set out to accomplish in the beginning either. It’s only through the thousands of different contributors, and hundreds of companies, all working together to make Linux better for them, has something like this evolved. It’s changed the way people think about software engineering practices, and how large projects can be run and constructed.
|
|
|
|
| Authored by: jtdsouza on Tuesday, January 05 2010 @ 03:29 AM EST |
I would add a mirrored Blue arrow on the right with some more tuxes symbolising
users who do not "contibute". They too benefit just as much.
---
jtd[ Reply to This | # ]
|
| |
| Authored by: Anonimuse on Tuesday, January 05 2010 @ 03:29 AM EST |
| . [ Reply to This | # ]
|
| |
| Authored by: Anonimuse on Tuesday, January 05 2010 @ 03:31 AM EST |
| . [ Reply to This | # ]
|
| |
| Authored by: Anonimuse on Tuesday, January 05 2010 @ 03:32 AM EST |
| . [ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 05 2010 @ 05:00 AM EST |
"Indeed, at first we wanted to open-source all of Unix's code, but
we quickly found that even though we owned it, it was, and still is, full of
other companies' copyrights," Love added.
Yes, but he was just some
rogue CEO. The company had no idea that some rogue CEOs were giving their code
away.
Cyp[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 05 2010 @ 05:15 AM EST |
Giving code away doesn't make others give code away.
And iff everyone actually thought that way, then it would be true.
Would iterated prisoners dilemma be a good analogy?
(P.S. "make" can have two meanings — force or cause — maybe some
people confuse them...)
\Cyp[ Reply to This | # ]
|
| |
| Authored by: BitOBear on Tuesday, January 05 2010 @ 05:19 AM EST |
I end up having this conversation several times a year.
There is a strong business case for "free" software.
Most of the organizations that want to sell something, don't want to actually
sell things like "an operating system" they want to sell "a
phone". In fact they probably couldn't afford the time and expense to
create an operating system if they wanted to.
So that leaves buying something. Now in going into this transaction you have two
points of expenditure, the up-front cost paid to even _try_ your ideas out, and
then the per-unit cost you will end up paying for each unit you produce and
sell.
There are basically four models available. Fully Binary Distribution code,
Source Build Distribution Code, Constrained Open Source, and Unconstrained Open
Source.
In terms of products or licenses, these have concrete examples. I'll stick to
"mobile device" grade examples to make them concrete.
In the Fully Binary Distribution model is the MS Windows, WinCE being the mobile
platform. You may be able to _read_ some or all of the code for WinCE, but you
can only distribute the OS parts when they come directly from the manufacturer.
In the Source Build Distribution model, used by VxWorks or RTXC, the
manufacturer gives you the OS code as source. You can modify that source and
distribute the binaries. You will own the patches and deltas, and you may be
able to give your patches to the source owner, and they will often use those
patches in future iterations of the core product. You will often, if you buy
support, have a very close relationship to the vendor.
In the Constrained Open Source model, like GNU/Linux, you get the source and can
distribute both the binaries and the sources, but you take on some requirements
along with the materials.
And finally, in the Unconstrained Open Source model, OpenBSD etc, you get the
source and you get to do anything with it while taking along no, or almost no,
requirements.
So given all that, there is a question of cost to initiate and the cost to
deliver.
For the non-open-source models, the cost to initiate is typically by a license
to the code base and a development "tool chain". This expense may be
considerable, and it is paid up front before you can even make experimental
forays. The cost is often per-seat for the development staff. Then on the back
end you may have to pay some amount per unit sold, or per so many units sold. In
these models, there is a large commitment that must be entered into at the very
inception of the project. Even experimentation may have a direct financial
cost.
In both of the Open Source models there is no up-front cost, and no cost per
unit. This is the primary attraction of the model. This is the part where the
"free" is "free as in free beer". Now there may, and from
many vendors there are, "improved" tool chains that are sold,
sometimes per-seat and with or without vendor support. The important thing here
is that such expenditures are completely voulentary and can be undertaken when
or if the need for tools become obvious. Even then, it may only be necessarily
to buy one or two such "seats".
Where the two different models of open source differentiate is in the per-item
cost of distribution. In the GNU/Linux model you agree to pay _disclosure_. This
is, in a business sense, a concrete expense. FreeBSD style licenses do not
require this disclosure.
Now, with this expense model, you have to ask what do I get for this expense.
The reward is feedback. It may not feel like a reward in and of itself, but
because this cost directly causes and fuels the ecosystem that makes the project
work. In a non-trivial project the two-way flow of code creates something
equivalent to a constrained support expense.
When treated this way, the cost of disclosure can then be moderated and
constrained itself. By asking what the "real value" of the disclosed
information might actually be, and separating sorting must, may, can, should,
and shouldn't(s) for the elements of the software, one can be judicious in the
design. For instance if the organization has a legal, fiduciary, or moral need
to keep some elements from distribution then those elements can be factored into
isolated application elements that are part of the overall system.
For example, a GUN/Linux host might be running a Oracle database engine, and
that database engine, while passing massive amounts of data through the Linux
kernel, the database engine has its wholly separate license, distribution model,
and a completely private internal structure. Whenever you get to a design that
cannot be so isolated, you may find that you have bought into an improper design
or impractical scheme (e.g. one that violates the basic principles of computer
science like modularity, semantic isolation, localization of design, functional
decomposition, and so on).
Like any business agreement or commitment, a smart businessman will seek to
understand the terms before he commits time and money. And when wisely handled
there is, for those so motivated, an opportunity to make money.
The same goes for the artist, or the programmer, who wants to make a impact or a
name for themselves.
But most important, the constrained open source model has proven most robust
because there are more people who want a better phone, or router, or computer,
or whatever by far, than there are people who want to make money selling a phone
etc. By joining a mutual disclosure model, the vendor buys potentially
exponential support structure for the logarithmically diminishing cost of simple
disclosure.[ Reply to This | # ]
|
| |
| Authored by: Crocodile_Dundee on Tuesday, January 05 2010 @ 05:29 AM EST |
I understand the GPL pretty well. But I understand it from the perspective of
someone who agrees with the philosophy of it rather than who has reluctantly
found that compliance was the lesser of 2 evils...
I'm also aware that there have been those who have wanted to USE code that was
licensed under the GPL, and who have been brought to the realisation that
without the GPL they have no rights, so they better damn well follow the rules.
However I'm not as familiar with cases where the copyright owner has released
code under the GPL and who then wants to, to put it mildly, reneg. The cases
I'm aware of seems to be festering sores rather than something with a simple
fix.
If I was to play Devil's advocate for a moment. Let's say I release commercial
code. I decide to remove some of my user's rights by attaching a EULA. Now
that EULA (generally) is primarily designed remove rights. The GPL, on the
other hand conditionally grants very broad rights. Are the rights that the GPL
grants in any fundamental way different from the rights that my EULA takes
away?
Let's say I have copyright over some code that is released under the GPL. The
GPL does not prevent me from releasing my code under a different licence, and
indeed I might release it under some closed source licence with a EULA
attached.
Notwithstanding the fact that any user may obtain my code from a pure GPL
source, what prevents me from selling (or indeed giving away) parts of my code
under some other licence that includes a EULA that takes away GPL rights that I
granted to any of my own copyrighted code? Indeed what prevents me from
attaching a EULA to anything I offer to remove rights that I have granted via
the GPL?
Naturally one might be foolish to accept something on those terms, but could I
get away with it? Well, more than that, could it claim victims?
I doubt that anyone would try this unless they wanted a name worse than SCO, but
that -- at least in some circles -- does include Microsoft. And Microsoft have
released some GPL code recently...
I'm always wary of EULAs, and have fallen asleep reading several. Is this yet
another thing I should be wary of.
---
---
That's not a law suit. *THIS* is a law suit![ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 05 2010 @ 06:44 AM EST |
I have been thinking about the difference between cooperation and competition.
The simplest description is:
- If you and I cooperate, then when you win,
I win too. If you lose, then I lose.
- If you and I compete, then when you
lose, I win. If you win, then I lose.
Destruction is easy, while
construction is hard work. So competition leads to desperate attempts to destroy
the other party, even if I cause damage to myself in the process: as long as I
manage to do more damage to you than I do to myself, then I
win!
Competitors cannot understand the GPL, they say things like: "Why would
I give away my code?". In reality, you do not give away your code: you
still have all the code you release under the GPL!
But releasing code under
the GPL helps other people: if you are competing, then helping someone else
causes you to lose. If you are cooperating, then helping someone else helps
everyone, including yourself, to win.
The GPL is like a lottery in which
everyone wins: "give away" your $1 and get $10,000,000 in return. Who
wouldn't want a deal like that?
The competitive spirit is illustrated by the
story of the man who rubbed an old lamp: out popped a Genie who offered him a
wish. He could wish for anything in the world. The catch was that his enemy
would get twice whatever he wished for.
So the man wished to be half
killed.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 05 2010 @ 07:16 AM EST |
The graphic makes it very clear why people are motivated to contribute to a GPL
project: you give a little and receive back a lot. It's very well done in that
respect. It captures the aspect that some people don't understand.
It doesn't capture the whole picture, however. As already mentioned you could
add a group of receivers who don't contribute.
Also the graphic doesn't mention GPL, it mentions Linux.
The graphic is not only true for GPL projects, people contribute to projects
with non-copyleft licenses. For those projects you could add a group of
redistributing users who don't contribute.
The problem is that adding extra groups of users and using less well-known terms
(I think more people will know about Linux than about GPL) weakens the picture.
The strength is in its simpicity.
Even though the graphic captures the essence of sharing, it still may fail to
convince a group of people. Here's why.
Long ago, somewhere in the 1980's I think, I read about an experiment where they
put people in situations where something was to be gained. People could
cooperate with others or compete. Sometimes cooperation was the most profitable
choice, sometimes competition. The result: about half the people would always
choose to cooperate, roughly a third would do whatever was most profitable, the
remaining sixth would always choose to compete. It turned out that the
cooperative ones could learn to understand how the other groups were motivated
and deal with it, while the people in the other groups remained convinced that
people making other choices than they would shared their motivation but were
less clever at playing the game.
This blind spot may explain why a model that is based on cooperation to achieve
mutual benefits can be so hard to grok for some. They may understand the graphic
in a superficial way, but still reject it as something that can't work because
they just aren't capable of understanding the underlying cooperative mindset.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 05 2010 @ 08:33 AM EST |
The graphic shows the complete GNU/Linux system flowing back to the people
who contributed it.
But that's not correct. The complete GNU/Linux system
can be used by anybody, whether they contributed to it or not. Probably most
GNU/Linux users did not.
So the graphic materially
misrepresents the effect of the GPL. No element of barter, no element of
"getting something in return for something", is involved. The two flows are
independent of each other.
[ Reply to This | # ]
|
| |
| Authored by: phaoUNTOtom on Tuesday, January 05 2010 @ 10:51 AM EST |
I realize this is not a graphic presentation, but I recently came across an
easy-to-understand analogy by theologian John M. Drescher that I feel very
accurately describes the GPL.
<analogy>
There was a corn farmer who won blue ribbons for his corn year after year. Yet
each year he shared his best seed corn with all his neighbors. "How do you
expect to continue to win blue ribbons," someone questioned him, "if
you give your best seed corn to others?" "You don't understand,"
said the farmer. "The wind carries the pollen from field to field. If I
am to have the best corn, I must see to it that all my neighbors also have the
best corn. If they produce poor corn, it will pollinate mine and pull my
quality down."
</analogy>
Yes, indeed. Some just don't grok the GPL. Their myopic scope--I dare say
mantra--is that their can be only one winner. The stark truth is that the
farmers, the resellers, the packaging plants, the grocers, and the consumers all
benefit from this synergistic relationship.
And then their are others who DO grok the GPL but who feign ignorance. As it
has been said many, many, many times before, "The rising tide lifts all
boats."[ Reply to This | # ]
|
| |
| Authored by: cricketjeff on Tuesday, January 05 2010 @ 10:59 AM EST |
I can't draw :)
But think of GPL software as a child's roundabout in a park, a HUGE child's
roundabout. It is free for everyone to use, you don't have to push, you can just
sit on and ride, but lots of kids will push and the more who do the more fun it
is, for the pushers and the merely pushed. Sometimes people will just walk past
and push for the hell of it.
No-one gets paid but the kids keep coming!
---
There is nothing in life that doesn't look better after a good cup of tea.[ Reply to This | # ]
|
| |
| Authored by: coats on Tuesday, January 05 2010 @ 11:08 AM EST |
|
Alexis de Tocqueville (perhaps the most
insightful analyst of the
American psyche) noted a
uniquely American penchant for forming
voluntary
community associations in order to deal with problems.
He further
stated that this tendency seems to be found
nowhere else on Earth: not in
Europe, not in the British
Isles, not even in Canada; it was a truly
American
contribution to human society.
And now the Internet has allowed
this uniquely American
contribution to spread world-wide, in the form of
open
source collaborations that have given us Apache, Linux,
and a host of other
software. It is indeed the SCOs,
Sonys, and Microsofts of the world who are
unAmerican,
who want to take us all back to a world of king-granted
(IP)
privilege.
For what it's worth.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 05 2010 @ 03:57 PM EST |
People do things for two major reasons, the first is money. Plain, fungible
cash as a means to provide all their other needs. The second is recognition.
Recognition is an interesting need in most people. Mounds of cash, by itself,
is not enough to keep people around. People need the public recognition for
their efforts. Professional societies are a result of that need. Recognition
is more keenly felt when it comes from experts in your field. (Several lawyer
recognitions are part of the bio's of the attorneys from each side.)
Contributing code is a way for a programmer to receive acclamation from the
experts in their field.
Companies pay programmers to contribute to FOSS, because it is less expensive
than keeping coders for the entire business stack in house. You have someone
with deep expertise in an application. More importantly, you have someone that
can get immediate answers and support from the other contributors to the
project. I vividly remember support techs being in high demand because they had
direct contacts at Oracle, Micro$oft or Novell. Those people were worth more,
because they got results faster.
The arguments about "keeping our IP" are silly. IP is of transient
value. Having workers who can utilize IP is the only source of business value.
The GPL was (and is) the best mechanism for keeping that valuable knowledge base
productive.
-- Alma[ Reply to This | # ]
|
| |
| Authored by: LaurenceTux on Tuesday, January 05 2010 @ 05:10 PM EST |
lets say that One day out in the desert a StarGate suddenly appears and then a
fleet of Puddle Jumpers flys out and then sets up a Power Distribution Center
(they have access to ZPMs or can actually make them in the center).
Within Days 80% of the businesses involved in power production are now obsolete.
Could they adapt quick enough to survive??
In the software business "StarGates" are a real thing that happens on
an annual basis (New OS comes out New API comes out Massive Problems with
formerly "safe" and "stable" APis hit ect). GPL and other
Open Source code means that the hit is shared with EVERYBODY so instead of
spending 200 million on the "Shift of the Moment" you as a business
pay your own people who then gather the fix and implement it.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Tuesday, January 05 2010 @ 08:16 PM EST |
This statement, if actually made by Mr. Love, indicates that HE didn't fully
understand the nature of the APA: The copyrights (and, thus, the actual
ownership) of the UNIX code was never actually transferred to Caldera, contrary
to this statement by him.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, January 06 2010 @ 01:01 AM EST |
A couple of problems with the graphic and article.
You should introduce the license by it's correct name, that is the GNU General
Public License (GPL). We all 'know what you mean', but I think it is worth
specifying correctly.
The graphic itself is a little weak, and doesn't really demonstrate why the GPL
in particular is such a powerfully binding force, and particularly friendly to
commercial players (which is why Linux has become so much more popular than any
BSD for instance).
It could equally apply to any 'open source' project, or even 'shared source'
(even pay-to-license-source).
The GPL is particularly friendly to commercial interests in a couple of
important ways:
1. If there is one owner of the copyright, ONLY they can re-license and sell
proprietary versions of it. Other commercial interests can add to the libre
version, but they cannot extend it in proprietary ways. But this has benefits
to both sides - the owner can perhaps make more money to provide a more sound
footing and stable direction for the project, and the contributor knows what
they're getting into. This also helps prevent forking - about all you're really
doing is lumping yourself with all the maintenance overheads if you try. (this
seems to be what Monty's beef over oracle is all about - he wants to go back to
the propriety value-add model for his fork, but the GPL prevents that).
2. If there are many owners of the copyright, then it also benefits all
contributors. They know nobody can fork it and make money purely off everyone
else's work. It lowers the risk of any work they do being exploited or being
locked away from them,
This is why M$ is so afraid of the GPL in particular - not because it's business
unfriendly, but precisely because it is (and likewise, they are not business
friendly to anyone but themselves).
These are not only from the perspective of the developer - unlike 'open source',
free software goes beyond merely using a license like the GPL. It provides the
tools AND strives to provide the documentation to allow any 'user' to also
become a developer if they so wish - so these benefits are available to all
users by extension.
The whole barter concept doesn't fit very well either. Barter is generally the
exchange of equivalent value goods or services. But in the ideal free software
project the value exchange is *all in one direction*.
i.e. on average, *everyone* gets *everything* for *nothing*
The diagram sort of tries to show this, but not very well.
This is an economic ideal far beyond the concept of barter, and only realisable
due to the frictionless aspect of information transfer afforded by the internet
and the wide availability of cheap and accessible development platforms.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Wednesday, January 06 2010 @ 04:51 PM EST |
- Caldera distributes Linux, believing that all the IP is properly GPL'd
- Caldera buys oldSCO
- SCO half of Caldera thinks there might be some Unix in the Linux they have
been distributing
- SCO begins investigations in to what files exactly are infringing
- In the meantime they continue distributing Linux
- Once they have all the research done, they stop distributing the infringing
files
- They can now argue to the court that it doesn't matter that they distributed
the code under the GPL, because at the time they distributed it they did not
know it was their own IP they were giving away[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Thursday, January 07 2010 @ 04:24 PM EST |
It's a very simplistic graphic; great for what it is trying to display, which is
not the GPL but rather a small part of a process which is facilitated by the
GPL, from a particular perspective.
This shows the exchange that occurs in a FOSS development model from a
contributor's perspective. I think a more complex graphic could include
non-contributing users, as discussed in the comments above. This would have the
end product moving from the project to the user. Again, as discussed above, it
could also show the benefits brought by non-contributing users like testing,
distribution, advertising etc. It could also show things like support moving
from contributors and the project (collectively titled the community?) to the
end-user.
However, a graphical representation of the GPL from a lawyer's perspective would
be different again; I would expect something explaining the legal consequences
and ins and outs of the GPL. i don't really now how this could be achieved, a
flow chart maybe? Lawyers love their flow charts...[ Reply to This | # ]
|
|
|
|
|
