|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Social aspects of the BSD vs. GPL debate
(Research notes to the e-book Labyrinth of Software Freedom )
Rui Miguel Seabra wrote:
> A copyright law violation is as severely pursued be it Free
Software as proprietary software
"The church of GNU denounce copyright as an evil plot... unless this
is connected with the direct attacks of the legality of GPL. ;-)"
-- Bezroukov
Letter by Alexander Telehov
Re
Use of GPL'd code with proprietary programs |
This page is a collection of my research notes to the ebook
Labyrinth of Software Freedom.
As any research collection it's mainly for the internal consumption and as such
is pretty raw. Still I think that software developers should be aware about misrepresentation
of copyright in GPL (and in general by RMS (aka FSF ;-) and here this page might
be somewhat useful.
GPL has problems typical for any utopia. Still it does include some positive
value. In
The Soul of Man Under Socialism, Oscar Wilde wrote that "a map of the
world which does not include Utopia is not worth looking at". As
Jon "Hannibal" Stokes aptly
noted:
Ars Technica Intellectual Property and the Good Society - Page 1 - (8-2001)
Each aspect of a structure--the choice of a foundation, the materials, the
location--reflects the values, interests, and goals of the person or group who
built it. This is nowhere more evident than in the international intellectual
property structures currently under construction by parties with an interest
in maintaining the status quo of the offline world into the digital age.
This global intellectual property regime is being developed quite deliberately
by a very select group of transnational corporations with vast patent, copyright,
and trademark holdings, holdings that are essential to their survival.
Furthermore, this group justifies their vision of how this structure is turning
out by using the language of rights--language that works to this group's benefit
in exactly the way I outlined above. By focusing the debate on the "rights"
of individual parties, this group has been able to distract us from the construction
work that's going on right under our noses. Make no mistake, this group may
talk "rights" to the public, but they're thinking "structures," and even a cursory
examination of the documents they produce will bear this out.
The type of structures that this regime is developing are outlined in a document
typical of it: a product of the World Intellectual Property Organization's (WIPO)
Workshop on Implementation Issues of the WIPO Copyright Treaty and the WIPO
Performances and Phonograms Treaty, entitled, "Technical Protection Measures:
The Intersection of Technology, Law, and Commercial Licenses." In this document,
the authors outline a three-pronged strategy for the "protection of intellectual
property." Again, it is important to note that this strategy was not developed
by content producers "on the ground," but is a product of transnational corporate
interests whose overriding concern is the maintenance of the status quo.
I'll summarize this strategy briefly, because it's important that each of its
three components be understood if those of us with an interest in the outcome
of these developments are going to be able to address them.
The first element in this strategy is the most familiar to the technical
crowd, as it involves the development of technological protection measures aimed
at "protecting" content from "unauthorized uses." The current focus
of the "content protection" industry is on the use of encryption and steganography
(i.e. information hiding techniques like digital watermarking) to control access
to digital works. The industry doesn't expect encryption to completely prevent
unauthorized copying, however. Rather, it is felt that encryption will enable
content owners to raise the level of difficulty associated with unauthorized
reproduction and distribution of copyrighted works. If it is suitably difficult
for a consumer to compromise the digital locks placed on published content,
the reasoning goes, then such "pirate" activity will be limited to the few,
the competent, and the dedicated. Content owners openly admit that this is a
direct attempt to artificially reproduce the constraints on copying naturally
inherent in analog media, thus doing away with the advantages of digital media
for everyone but the content owners themselves.
Open/free software licenses probably are farther from the "traditional" copyright
law than an approach discussed in the quote above. To a certain extent they are
connected to the political notions of freedom and power (like in "Power without
freedom is tyranny. Freedom without power is impotent."). RMS chronic abuse of the
word "freedom" and simplistic (anarchistic) understanding of this complex issue
is very symptomatic in this respect. That's why
www.gnu.org sometimes reminds
a web site of some obscure "software cult". In no way it can be considered a software
developers website despite the fact that RMS was in the past a programmer himself.
It's important to understand that the material presented covers a pretty limited
spectrum of questions raised in my e-book
Labyrinth of Software Freedom.
My impression is that GPL outlived its usefulness and that the Artistic license
(Plan 9 license generally can be considered as a longer and with more legalize derivative
of the Artistic license designed for corporate use) can serve as an alternative
for GPL on early stages of software development (especially if there is some public
funding involved). Sun Community Software License is probably another interesting
underutilized license that can be used on early stages of software development cycle.
BSD license is better for mature software and here GPL is simply inadequate.
It also has problems with enforcing zero price (price fixing) that was first
shown in two Wallace lawsuit that was dismissed on technical grounds. In both cases
the GPL was not upheld - Wallace's complaint was dismissed without discussing its
merits at the request of FSF (FSF
Tries Again To Get GPL Antitrust Suit Dismissed @ ENTERPRISE OPEN SOURCE MAGAZINE)
The Defendant FREE SOFTWARE FOUNDATION INC. has entered into contracts and
otherwise conspired and agreed with individual software authors and commercial
distributors of commodity software products such as Red Hat Inc. and Novell
Inc. to artificially fix the prices charged for computer software programs
through the promotion and use of an adhesion contract that was created, used
and promoted since at least the year 1991 by the FREE SOFTWARE FOUNDATION INC.
This license is known as the GNU GENERAL PUBLIC LICENSE. The price fixing scheme
implemented with the use of the GNU GENERAL PUBLIC LICENSE substantially
lessens the ability of individual software authors to compete in a free market
through the creation, sale and distribution of computer software programs. [emphasis
mine]
The ruling was:
"First, while Mr. Wallace contends that the GPL is "foreclosing competition
in the market for computer operating systems" (id.), his problem appears to
be that GPL generates too much competition, free of charge. The court's understanding
from the GPL itself is that it is a software licensing agreement through which
the GNU/Linux operating system may be licensed and distributed to individual
users so long as those users "cause any work that [they] distribute or publish,
that in whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties under the
terms of this License." (GPL 3.) The GPL purportedly functions to "guarantee
[users'] freedom to share and change free software." (GPL Preamble.) As alleged,
the GPL in no way forecloses other operating systems from entering the market.
Instead, it merely acts as a means by which certain software may be copied,
modified and redistributed without violating the software's copyright protection.
As such, the GPL encourages, rather than discourages, free competition and the
distribution of computer operating systems, the benefits of which directly pass
to consumers. These benefits include lower prices, better access and more innovation.
See Jason B. Wacha, Taking the Case: Is the GPL Enforceable, 21 Santa Clara
Computer & High Tech L.J. 451, 487 (2005). And the Sherman Act "was enacted
to assure customers the benefits of price competition, and . . . prior cases
have emphasized the controlling interest in protecting the economic freedom
of participants in the relevant market." Assoc.'d Gen. Contractors v. Cal. State
Council of Carpenters, 459 U.S. 519, 528 (1983). Therefore, the court
finds that the Fourth Amended Complaint does not adequately set forth an injury
to competition as a whole."
- John Daniel Tinder, Judge, United States District Court,
Daniel Wallace
v. Free Software Foundation, Inc.
It looks like Wallace discovered in interesting property of GPL that previously
was never discussed: In the article of the
Stanford Center for Internet and Society "Court Finds No Antitrust Injury From
GNU General Public License (GPL)" the substance of Wallace claims was outlined as
follows:
This case involves the GNU
General Public License (GPL), which governs the use of many products sold
and distributed by the Free Software Foundation (FSF), including GNU/Linux operating
systems. The GPL requires, among another things, that users who distribute or
publish any work derived from GPL-covered software to license that work to under
the GPL to all third parties at no charge. The plaintiff, Daniel Wallace (Wallace),
was not a user of FSF software; rather, he was a competitor of FSF’s, trying
to sell his own operating system. Wallace brought an action pro se against FSF
claiming that it was conspiring with commercial distributors IBM, RedHat, Novell,
and others to fix prices for intellectual property in the market by attaching
the GPL to GNU/Linux operating system software. Wallace claimed, in essence,
that the GPL constituted a horizontal price-fixing scheme among competitors
in violation of Section 1 of the Sherman Antitrust Act and sought to enjoin
FSF from developing and distributing Linux under the GPL. On motion
by FSF, Judge Tinder of the United States District Court for the Southern District
of Indiana dismissed the complaint for failure to show any “antitrust injury”
from FSF’s conduct, but held that Wallace had otherwise stated a claim upon
which relief could be granted.
In his third amended complaint, Wallace alleged that FSF was conspiring with
its competitors to fix prices for software via the GPL. The court determined
that Wallace was effectively claiming the existence of a horizontal price-fixing
agreement, which would be illegal per se under the Section 1 of the Sherman
Antitrust Act (prohibiting contracts and conspiracies in restraint of trade)
because such horizontal arrangements are perceived to have a “pernicious effect”
on competition. By comparison, vertical agreements (those between enterprises
at different levels within the same chain of distribution) are governed by a
“rule of reason” analysis because their effects will not always be anticompetitive.
The court determined that the GPL could not be reasonably characterized
as a horizontal agreement because it governs agreements between licensees and
licensors, who are users at different levels within the same chain of distribution.
Therefore, the court reasoned, the GPL is a vertical agreement, and it cannot
alone constitute a per se violation of the Sherman Act.
The court then analyzed the GPL under the rule of reason to determine whether
it might be an unreasonable restraint of trade. Under the rule of reason, a
vertical licensing agreement may violate the Sherman Act if it produces adverse,
anti-competitive effects such as a reduction in output, increase in price, or
deterioration in the quality of goods and services, among other factors. FSF
argued that its practice of allowing free access to software with the GPL aids
competition rather than hinders it. However, the court held that the GPL may
have an anticompetitive effect by discouraging software developers from creating
better programs for Linux (since they could not be adequately compensated) and
reducing the number of quality programs available to consumers. Thus, Wallace’s
complaint sufficiently alleged a violation of the Sherman Act.
However, the complaint ultimately failed because the court found that
Wallace had suffered no antitrust injury, i.e., injury of the sort that the
antitrust laws are designed to prevent. Examining Wallace’s complaint,
the court found that his only alleged injury was an inability or unwillingness
to enter into the software business because he could not compete with users
of Linux. Because this is an injury to a (potential) competitor rather than
an injury to consumers or to competition itself, the court found no antitrust
injury and dismissed the complaint.
Due the size of the page software licenses catalog
was moved to separate pages. There are two common misconceptions that I would like
to point out.
-
The first very common misconception that many people confuse "GPL", and "Open
Source". Open source is actually an umbrella term and it is more correct to
distinguish between OSS under particular licenses: Artistic license, BSD, GPL,
MPL and several other less popular licenses. GPLed software represents less
that 50% of "open source" code; the majority of "open source" code is made up
of BSD, Artistic license (and its derivatives) and the other license types.
-
The second misconception is that open source is considered to be mainly Linux-related.
In reality BSD operating systems and BSD-licensed software is older, in some
areas more prominent and more technically advanced branch of open software space.
While Linux might be getting all the ink, at least in ISP world BSD is doing
most of the work (BTW Yahoo is running on BSD).
I actually like the 'you get something for free, you have to give something back'
idea, however, I like it from the point of view of academic ethics; I don't like
the GNU manifesto, I don't like Stallman's ideas about commercial software (and
yes, I mean Microsoft as a example of commercial software vendor ;-), and I really
don't like people who blindly follow software anarchists like Stallman.
Again, this is a "slightly skeptical" page. If someone decides to license
software under the GPL, that's fine, but that should be done by looking at the license,
reading relevant discussions, papers and historic cases and seeing what it's all
about (and what the consequences are). Most Linux programmers however, blindly stamp
GPL on their programs. Sometimes they are naively thinking that they prevent companies
to profit off their work, forgetting that companies like IBM, RH, Suse (now Novell)
are profiting from them already.
Finally, there are a some systemic things about the GPL/LGPL that I don't like:
they are too complex, too vague, contain too much irrelevant information, and are
too restrictive in case of object oriented programming (you might need a new license
to get the equivalent of what the LGPL is for non-OO languages).
The other interesting topic that I added recently is
abandonware.. This is a rapidly growing phenomenon
and it has some grass root support. It probably will need a separate page really
soon ;-). The term anbandonware is usually applied to commercial software (like
Norton Commander, DOS, MS Word for DOS, WordPerfect for Linux, etc). But we need
to understand that most open source projects listed say on Freshmeat are abandonware.
Few are actively maintained and of those even fewer are useful. Quantity does not
turn into quality automatically. See also the Usenet group
misc.int-property
for relevant discussions.
Dr. Nikolai Bezroukov
|
|
Notes:
- This is a Spartan WHYFF (We Help
You For Free) site written by people for whom English
is not a native language.
Some amount of grammar and spelling errors should be
expected.
- The site contain some broken links
as it develops like a living tree...
Please try to use Google, Open directory,
etc. to find a replacement link (see
HOWTO search the WEB for details). We would appreciate
if you can
mail us a correct link.
|
|
|
As "Via archive.org, one can see that the default OEM agreement included restrictions
on modifying the source since at least June 2005" why Monty is trying to blackmail
Sun ?
Aug 4, 2009 |
Monty says
History
The first example of dual-licensing was probably
Ghostscript, which Peter Deutsch licensed first under the GPL and later
under the Aladdin Free Public License, but also under a proprietary license.
Inspired by his idea, David Axmark and I released MySQL under similar dual-licensing
terms. Dual licensing has since become one of the most common and popular ways
to create profit centers around Open Source/Free Software, in addition to support
and services around the product.
To be able to bootstrap MySQL Ab, we originally had a license that allowed free
usage, but a "pay-for" license if you used MYSQL for commercial usage or on
the Windows platform. In 2000 we changed the free license to GPL, mostly to
avoid having to explain our own license to everyone.
The basic idea for our dual-licensing was this: if you bought a license then
we waived the GPL restriction that you have to redistribute your code as GPL.
You could change, modify, extend, distribute, and redistribute the copy in any
way you wanted (but of course not change the license of the MySQL code). The
license was for any version and usage of MySQL, for now and forever.
This is still reflected in the
MySQL FAQ on this topic.
This is what I personally think is the appropriate way to dual-license open
source software and how we intend to do it in my new company, Monty Program
Ab, for the software we produce.
The MySQL OEM License
I was recently made aware that the above is no longer the case with the standard
MySQL OEM agreement. Sun is now, by default, putting the following limitations
on their licensees:
(Sun has, of course, all rights to put any restrictions on their code, but as
this is not how dual licenses used to work with MySQL or how it works with other
Open Source projects (See for example, the license information for
Ghostscript and .) You should however be aware of these issues if you intend
to ever acquire a commercial license for MySQL)
- You cannot modify MySQL in any way (for example to fix bugs,
optimise MySQL for your applications, include publicly available enhancements
(such as the BSD licensed "Google patch" or compile it with another storage
engine) to improve your MySQL as part of your product.
- You cannot use any forks of MySQL (such as Drizzle, ExtSQL
or MariaDB).
- You are tied in to the current major release of MySQL enterprise
(i.e. you have to pay for upgrades). This may be normal in a closed source
environment, but not normal when it comes to Open Source.
- There are serious limitations for what kind of applications
you can build with the MySQL code, for instance, the default agreement prohibits
installations in hosting facilities or to use your version as a SQL server.
- The end user can't transfer/sell the license to someone
else (to be used under the same conditions).
Recommendations to licensees and those considering the purchase of a MySQL
license
With above limitations in place, you should consider if it's worth it to you
to buy licenses for MySQL under the current terms. Also, if you are an old licensee
of MySQL, you should be careful to review any new conditions when your license
is up for renewal. Note that this warning is not something specific to Sun but
applicable when working with any software vendor.
If you are running an old, modified, community, or forked version of MySQL at
your company, you need to be aware that the default OEM agreement is not applicable
to you. This also the case if you modify MySQL code to implement a new storage
engine, MySQL extensions or if you are a hardware vendor that wants to to tune
MySQL for your setup.
If you need to buy a commercial license, because you cannot use the GPL, you
need to seriously consider if you can accept the default restrictions. If not,
then you should contact Sun and renegotiate the terms. I know there are examples
where MySQL licensees have been allowed to change MySQL code and also have the
right to publish those changes (Infobright
openly advertises that they've done so). You should ask to get those same rights.
If you plan to do dual licensing yourself, you also need to make sure that the
license allows you to use an Open Source version of MySQL with your Open Source
product.
When agreeing to a license, ensure that you get enough freedom to do what is
required for your business and you are not completely dependent on one vendor
for your success!Recommendations for companies doing Dual-Licensing
I believe one should be very permissive when doing dual licenses with Open Source
as otherwise you lose many of the business advantages you get from being Open
Source. The Open Source community is a very effective ecosystem and if you allow
it to participate with your business you have a better chance to succeed.
The only restriction you need when re-licensing is that the licensee should
not be able to change the license of your code and they can only use and/or
distribute the pre-negotiated number of copies of it.
- Allowing changes to the licensed code allows the licensee
to combine community code and their own code in creating a better product.
It also gives your customer more trust in your product as they don't feel
locked into only one vendor for things like bug fixes and enhancements.
- Make it easy to use your product or part of your code with
other products.
- Allowing re-distribution of the product creates a market
for people doing addons, enhancements and totally new products based on
yours.
- Don't be afraid of forks; They enlarge your ecosystem and
anyone that wants to buy a license for these forks also has to buy one from
you.
- Don't limit the license to a specific version; If you allow
changes this is meaningless anyway as one can easily go around it. In the
long run it's not a winning proposition to sell the same software over and
over again to the same customer. Instead work on the software and with the
customer to increase the usage of the software.
- Don't limit in any way how the product/code can be used;
it just forces people to choose or develop other products that will compete
with you and will limit the business you can create.
- Make the end-user license transferable. This is already
allowed in many countries, it is what normal people expect from most things
they buy and will create opportunities for new business by others. If you
got paid for any copy of your software that exists, do you really care who
uses it second hand ?
By being fair to others, you will get a reputation as a trustworthy business
partner and you will get more business in the long run.Recommendations to
Community contributors
I assume for this blog that it's clear why it's beneficial for you to donate
code to an Open Source project. (If not, then this could be a topic for another
blog post).
However, when donating your code to a an Open Source project that is using dual-licensing,
you need to also consider how the project is going to use your code when re-licensing
it under a non-Open Source license. This is very important if you ever want
to license the project yourself under a commercial license (not Open Source).
- What are the restrictions on how you can use the re-licensed
work? (Ideally it should be usable for any purpose and in any manner).
- What changes can you make to the code when you re-license
it? (Ideally there should be no restrictions, except that you can't change
the license).
- Can an licensing agreement be used to restrict the licensee's
possibility to publish their own code as Open Source, or to include Open
Source code in their product?
- Is the re-licensing agreement tied to a specific version
of the project.
- Is the contributor agreement for the project clear in terms
of how you may donate code to it? Can the project, for example, take any
code you ever send to any related email list or do you need to explicitly
sign every contribution separately. (Our contributor agreement wasn't clear
in this aspect, so I recently added: "Each
submission must explicitly be marked that it's donated under the MCA".
You can of course also mark the code to be under BSD.)
If you agree with the above and you have signed contributor agreements that
do not include such a note, you should consider contacting those projects and
asking for a new one with such a clause or get some other public guarantee that
the project re-licenses code in an appropriate manner.
Note that releasing your code as BSD for a project that has or may have GPL
code doesn't protect your code from being dual-licensed in an unfavorable way.
The only way to ensure full freedom for others is to only donate your code under
a contributor agreement with a clause as suggested below or to a project that
has agreeable guidelines for how they license their code!
To assure our users, contributors, and customers of how we at Monty Program
Ab intend to re-license the code we produce or the code people donate to us,
I have added the following note to
our contributor agreement:
"Monty Program Ab agrees that when it dual licenses code, it will not restrict
the way the third party licensee uses the licensed copy of the code nor restrict
how they use their own code."
If you have any comments/ideas around this, feel free to join the the
maria-discuss Launchpad team and its associated mailing list and discuss
this topic.
Posted by Monty
at
23:59
Labels:
licensing Dual-licensing,
OEM
Selected comments:
There are four fundamental questions/topics in open source:
- Open-source licenses and the availability of source code;
- The impact of free (as in cost) software;
- The value of brand. As Red Hat knows, Red Hat is indomitable because
of its brand, not its source tree;
- Who's asking? The answer you give to an 8-year-old is different
from the one you'd give to a CIO. This last topic provides the answer
to the open-source revenue question.
... ... ...
I don't expect many college students, developers, or start-ups to spend
a lot of money on intellectual property. I expect someone whose job is on
the line if a system fails to spend considerably more than nothing.
The key is figuring out the difference between
one's market and one's community. They are not the same.
On the GPL, Apache and Open-Core
Matthew Aslett, August 28, 2009 @ 5:48 am ET
Jay has already
provided a good overview of the debate related to the
apparent decline in the usage of the GPLv2. I don’t intend
to cover the same ground, but I did want to quickly respond
to a statement made by Matt Asay in his
assessment of the reasons for and implications of
reduced GPLv2 usage.
He wrote:
“as Open Core becomes the default business model for
‘pure-play’ open-source companies, we will see more
software licensed under the Apache license”
I don’t doubt that we will see more software licensed
under the Apache license, and also more vendors making use
of permissively-licensed code, but I don’t see a correlation
with the Open-Core model.
In our report, “Open
Source is Not a Business Model“, report we found that
23.7% of the 114 vendors we covered were using Open-Core as
a vendor licensing strategy. Looking at the stats, over 70%
of Open-Core strategy users also used a variant of the GPL
or LGPL.
The main reason for the correlation of the L/GPL and
Open-Core is, as Matt notes, that “the GPL makes sense in a
world where vendors hope to exercise control over their
communities”. Carlo Daffara
agrees: “the GPL is not a barrier in adopting this new
style of open core model, and certainly creates a barrier
for potential freeriding by competitors”.
Carlo cites as an example the use of the GPL by the
usually Apache-focused SpringSource for its SpringSource dm
Server as a means of restricting the commercial
opportunities for potential rivals, something that we
covered
here.
As Matt explains, however, “if the desire is to foster
unfettered growth, Apache licensing offers a better path”.
Savio Rodrigues
offers an example of a usually L/GPL-focused company -
Red Hat/JBoss - choosing the Apache License for its new
HornetQ messaging software because “the project team felt
that the Apache license would ensure that the project’s code
could be more easily included into products from the
ecosystem.”
1-1 then. But this isn’t about point scoring. What the
examples demonstrate is that vendors choose licenses for
individual projects/products based on pragmatic business
reasons rather than dogmatic commitment to licensing
philosophy, and that - as we previously
suggested - there is actually some benefit in the
proliferation of different licenses.
Of course it is also important to remember that many
vendors don’t have the luxury or choosing a license for the
project they attempt to commercialize. Mike Olson
notes that adoption has been a factor related to the
Apache licensed Hadoop project - but what came first
commercialization or adoption?
I believe we are seeing increased adoption of
permissively-licensed open source software by both new open
source specialists, such as Mike’s Cloudera, and also
proprietary vendors such as Oracle, SAP and - as recently
discussed - Day Software.
In these cases, the commercial vendor doesn’t choose the
Apache license for software to encourage widespread
adoption, it is encouraged to choose Apache-licensed
software because of widespread adoption (not to mention the
low cost and high quality advantages of being part of a true
developer *community*).
That has more to do with the
patron model, as discussed by Day Software’s chief
marketing officer, Kevin Cochrane, than it does Open-Core.
Additionally, as Carlo notes, it is a product of the
shift towards what he calls “consortia-managed projects”. Or
as I previously
stated: “if Open-Core was a significant revenue strategy
of open source 3.0 (vendor-dominated open source projects
such as MySQL, JasperSoft), then Embedded [as I was
referring to the patron model at the time] is one of the
commercial open source strategies of open source 4.0
(vendor-dominated open source communities such as Eclipse,
Symbian).”
So while we expect Open-Core to remain a significant
business model for ‘pure-play’ open-source companies, and we
expect to see more software licensed under the Apache
license, we don’t see the two as being directly related.
Anyway, this was supposed to be a quick post. That’s
enough for now.
I have spent
years advocating the GNU General Public License as the
optimal open-source license for commercial open source.
Roughly nine years after I first became a fan of the GPL,
I think I've been wrong.
My admiration for the GPL mostly stemmed from its ability to mimic, but then
invert, proprietary licensing. The GPL is like opening a cannister of radioactive
waste: while your competitors can touch it, you're dead certain that
they won't.
Given that openness is increasingly a winning business model--if not the
winning business model,
as Red Hat executive Michael Tiemann argues--one has to wonder if pretending
to be open through the GPL accomplishes as much as fully opening up through
Apache-style licensing would.
Open-source luminary Eric Raymond is
pretty clear on this point:
I think we live in a...universe...in which the
GPL is unnecessary rather than futile. Mind you, I
am not claiming the GPL is entirely useless. It's a signaling behavior,
like wearing a crucifix or yarmulke or pentagram; it helps build trust groups.
But it has costs, too.
It creates a lot of needless fear from potential allies and users who
suspect they won't be able to control their exposure, if they let it in...Is
the GPL's utility as a form of in-group signaling worth the degree to which
fear and uncertainty about it slows down open-source adoption? Increasingly,
I think the answer is no.
The GPL may be a community-building signaling device, but it is also
a confession of fear and weakness. To believe that it matters, you have
to believe that you live in a...universe where closed-source development
is such an attractive proposition that you have to punish people for trying
to move to it.
In other words, if openness works (in
the Jamesian, pragmatic way), why not give it free rein, rather than hedging
our open-source bets to the point of obviating their efficacy?
Equally important, we may not be getting the "protection" we seek from the
GPL, anyway, as the
GPL becomes the new BSD in the cloud, as Linus Torvalds recently commented
to me in an e-mail:
AGPL/GPLv3 anti-ASP/TiVo language doesn't "protect" anything. There is
no upside to pushing freeloaders away.
Sun Microsystems CEO
Jonathan Schwartz rightly identifies adoption,
not protection of freedom, as a key open-source benefit: open source provides
an efficient way to distribute software to the maximum audience at the minimum
price. With this in mind, unfettered Apache-style licensing would
be the ideal license to maximize adoption, despite likely being the worst way
to directly monetize software.
So long, however, as one's business either monetizes software indirectly
(i.e., Google with its advertising model) or adds to the open-source components
with commercial extensions (i.e., IBM with proprietary software, services, and
hardware add-ons), then a company should be able to reap a bounteous harvest
from its open-source seeds.
In sum, the
GPL may well be an excellent capitalist tool, but Apache licensing could
well be even better.
Disclosure: My company uses the GPL, not an Apache license.
[Apr 30, 2009] GPL License Issues
rms_and_the_fsf
July 04, 2006
A look at the impact of the GPL on free software development.
If that's the case, perhaps Richard Stallman should rewrite the GPL so
that it doesn't (rather effectively) hinder small, grass-roots, free software
development and distribution projects.
Perhaps he ought to use his influence to stop the Free Software Foundation
from using the clauses already in the GPL as
an excuse to bully small free software development and distribution projects
with its legal heft.
MEPIS wasn't the only distribution targeted: also take note of the threat
of legal action looming over other projects such as Kororaa Xgl LiveCD.
John Andrews of Damn Small Linux reportedly
agrees with the estimation of MEPIS' founder Warren Woodford that a great
many small Linux distribution projects are at significant risk, and new
projects are considerably less likely to spring up in the evolving legal
climate of the "free" software community.
"how much more trouble is it to set up a source code tree and allow people to
access it?"
Easy to say if you're not paying for the bandwidth, or with the Mepis example
above, the time and materials to burn, package, and ship the DVDs. There's a
reason the hippie communes all fell apart. Peace, love and harmony are fine
concepts until it comes time to pay the bill, or actually get something done.
Simple fact is, even under the GPL, the source is freely available, but the
work/resources required to convey it from source to destination are under no
such restriction - and shouldn't be.
That said, if Zenwalk isn't making their source code available, they should
at least implement something along the lines of the Mepis solution.
rijelkentaurus
May 23, 2008
12:47 PM GMT Yeah, if I was burning the DVDs to order (or even several
at a time), you could probably figure about 15 minutes of time to get it done
per set, and that translates to $38.75 at my current billable rate (oh, if only
I was the one getting $155/hr, alas, it is my employer).
bigg
May 23, 2008
12:48 PM GMT I wouldn't trust a distro that doesn't have at least
a local copy of the original sources. When you download something, put a copy
in a folder on your hard drive. When someone contributes, make them give you
the original source.
I have no use for anyone who thinks he/she can ignore a software license because
complying is inconvenient. In addition, any responsible developer knows you
should keep a copy of the sources. A few GB on a hard drive. No big deal. Slap
it on a DVD and mail it to someone that wants it. If there were anything difficult
about complying with this rule, I would be at least 1% sympathetic.
> They have a script for users that supposedly pulls sources from upstream
Then what are they whining about? They can just run the script themselves. Problem
solved.
What are they going to do if there's a bug and the upstream source is no longer
available?
tuxchick
May 23, 2008
12:50 PM GMT You're ranting at the wrong people, dumper. No sources
are freely available unless someone makes them available, and the GPL specifies
exactly how to make it available. "Go find it yourself somewhere upstream" is
not one of the allowed methods, and people who expect Linux distributors to
honor the GPL are hardly dopey hippies with crazy ideas.
There is a simple rule for using GPL code: if you don't want to honor the terms
of the GPL, don't use GPL code. Mepis and Zenwalk are the ones who are balking
at paying their GPL bills, which is merely making their source trees available.
I daresay that is considerably cheaper than creating and maintaining an entire
operating system with productivity applications from scratch. They're getting
the benefit of gigabytes of other people's code, and yet they're still whiny
and ungrateful. Warren is displaying bad faith with DVD-only distribution at
an inflated cost, even if he is technically, by a hair, in GPL compliance, and
his licensing FAQ is full of errors. Users who want the sources for a single
or a just a few applications are stuck with buying the DVD set, and there is
no way of knowing how up-to-date the DVD sets are, or how soon they will receive
them.
I don't understand why "little guys" like Mepis and Zenwalk should get a pass
on GPL violations- they're in the wrong just as much as any BigEvilCorp that
does the same thing.
dumper4311
May 23, 2008
1:51 PM GMT Easy tuxchick - take a deep breath. I'm not ranting at
anyone, and we fundamentally agree. I believe any user of any code should comply
with said code's license. I further believe that under the GPL, any applicable
code should be made available in a reasonable manner.
We part company in that I don't share your bent towards entitlement. Mepis and
Zenwalk and anyone else using GPL code should be held to the same standard as
anyone else. You seem to have re-defined that standard to mean "they should
provide free, immediate access to everything for everyone." I view that as unhealthy
and irrational. Sadly, the effort to re-define "free" software as the technical
equivalent of a welfare state is becoming a common sentiment.
- Yes, they should honor the license of the code they redistribute.
- Yes, they should provide current code when it's requested.
- Yes, they should provide it to anyone who requests it.
- Yes, it should be done at a reasonable cost - what they reasonably feel it
costs them to maintain and distribute such resources.
- No, they're not under any obligation to provide instant access to such code.
- No, they're not obligated to let you decide for them what you feel a reasonable
fee is for such provision.
- No, they're not obligated to play indentured servant for anyone, and sort
through gigabytes of code for someone who only wants this . . . and this . .
. . and this, but not this . . . or this.
I never claimed "people" who expect anyone else to honor the terms of a given
software license are "dopey hippies with crazy ideas". Although it's cute how
you'd associate your perspective with that of "people" as a whole - we think
very highly of ourselves, don't we? :)
What I am saying is that the irrational entitlement motif you seem to be championing,
if codified, would tend to cripple the freedom you claim so loudly to respect.
Once again, passion is worth very little if it can't be balanced with a practical
implementation that serves the users of the software.
azerthoth
May 23, 2008
2:11 PM GMT
| Quoted:
|
|
to give any third party, for a charge no more than your
cost of physically performing source distribution |
Neither GPLv2 or v3 says anything near that.
GPLv2 Section 1
| Quoted:
|
You may charge a fee for the physical act of transferring
a copy, and
you may at your option offer warranty protection in exchange for a fee. |
GPLv3 Section 4
| Quoted:
|
|
You may charge any price or no price for each copy that
you convey, and you may offer support or warranty protection for a fee. |
It is a misconception that I have run across that you cant make a tidy profit
off of source code. I can take and put source code on a CD/DVD and charge a
thousand bucks for it if I chose. Granted that the first CD/DVD to go out can
then be shared wholly or in part for free.
Free as in Freeloader does not apply to source code either, a GPL project can
make the source code prohibitively expensive. Sorry if I seem a bit short TC,
I'm writing this before my first cup of coffee.
tuxchick
May 23, 2008
2:20 PM GMT
| Quoted:
|
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange;
or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange;
|
[HYPERLINK@www.gnu.org]
azerthoth
May 23, 2008
2:58 PM GMT Thank you TC, you missed
something in your reading of Section 3 though. Section 3.b kicks in (cost of
the act) only when you choose alternate compliance from sections 1 and 2 as
listed in Section 3.a.
Section 3.b as alternate compliance limits cost, Section 3.a has no such limit.
I'm not saying anything about Mepis or Zenwalk compliance in this, just that
the presumption that source code has a mandatory minimus charge is incorrect.
*edit* a good place for an example of charging in extremis would be the FSF
itself. [HYPERLINK@agia.fsf.org]
*/edit*
jdixon
May 23, 2008
3:49 PM GMT
> Easy to say if you're not paying for the bandwidth,
Meer.net provides DSL service with a fixed IP address in the Morgantown area
for $45 a month and don't restrict you to non-commercial uses. Yeah, the speed
would be lousy, but the GPL doesn't address that, and if Warren is so absolutely
certain nobody needs the source, there shouldn't be that much demand for it,
should there?
dumper4311
May 23, 2008
5:07 PM GMT
"Yeah, the speed would be lousy, but the GPL doesn't address that . . ."
Then you're still left with the same complaints (from the same complainers)
I tried to address in my second post. Now it'll be "with this crappy connection,
I still can't download and they're violating the "spirit" of the GPL". It's
the same slippery entitlement based slope, with a twist of rationalization to
make it more palatable. So let's add another point:
- No, they're not obligated to let anyone else decide (outside of the explicit
declarations of the license) what is a reasonable method of distribution for
them.
tuxchick
May 23, 2008
5:31 PM GMT
heh, dumper, that's some world-class straining at gnats there. Indentured
servant? Sorting through code for someone else? Please, give me one example
of where this will happen by providing an ordinary source tree online. I know
when I need to fetch source tarballs, SRPMs, or get something from SVN I don't
need anyone else to "sort" them for me, and I rather doubt anyone else does
either. Where do you get this stuff? The "medium customarily used for software
interchange" is via Internet download, and in the FOSS world it's been that
way for years. The only "Irrational entitlement" here is from Zenwalk and Mepis,
who should really be using BSD code since they're so GPL-averse.
dumper4311
May 23, 2008
6:07 PM GMT
"Users who want the sources for a single or a just a few applications are
stuck with buying the DVD set,"
I got that from you , tuxchick. You're right, it wouldn't happen by providing
an ordinary source tree online, but you've also completely skirted the point:
You have no right to determine for them what method of distribution they choose.
Distribution via media is perfectly valid, whether you like it or not. It's
you straining at gnats, to somehow try to validate your entitlement mindset.
>"The "medium customarily used for software interchange" is via Internet download"
So declares tuxchick - ah, the arrogance of elitism. And in typical "I am entitled"
fashion, you'd dictate to these developers (translate: "free" code users) just
what their "freedom" means, and exactly how it can be exercised. Your position
sounds more like an MS EULA than a "free" software license.
>"Zenwalk and Mepis, who should really be using
BSD code since they're so GPL-averse."
Mepis is apparently complying, just not in a manner you care for. Zenwalk should,
we don't even have anything to argue about here. Sadly, it's not the GPL you're
arguing for.
I must admit, arguments like yours make me curious to see what the GPLv4 would
come out looking like following your ideology. As I said, this "communities"
more passionate members look more like a welfare state all the time.
jdixon
May 23, 2008
11:02 PM GMT
Now it'll be "with this crappy connection, I still can't download and they're
violating the "spirit" of the GPL".
And your point is?
Your were saying that the bandwith costs were a concern. I pointed out that
they weren't. The only reason Warren doesn't provide a source code tree is because
he doesn't want to. Why he doesn't want to isn't something I'm worried about,
since he is complying with the GPL (unlike Zenwalk), but there's no reason to
sugar coat the matter.
Added: Yes, I'm somewhat sensitive on the matter, since Morgantown is only about
30 miles away as the crow files.
BTW, in the judgment of folks here, would providing a Bittorrent feed meet the
requirements of the GPL?
dumper4311
May 24, 2008
1:49 AM GMT
@jdixon:
I'm not actually trying to sugar coat anything, or even trying to stick up for
Mepis or Zenwalk. I happen to agree with your first post in this thread (and
indirectly tuxchick's argument) - a good SVN repository on even a moderate connection
is reasonable - if they're worried about cost, they could charge a reasonable
fee for access to the repository, and change access permissions monthly or something
to help pay for it.
My point is there's always a reason to gripe if you don't like the way someone
else does something. As of yet, nobody's offered an intelligent reason to believe
the "community" is entitled to any special consideration beyond strict compliance
with the license. That's the part I have a problem sugar coating. :)
The Bittorrent question is interesting. By tuxchick's definition, it is a medium
"customarily used for software interchange . . . and in the FOSS world it's
been that way for years". Case in point - any number of ISOs for any number
of distros. I'm not sure it's any more convenient or accessible (or customary)
than ordering a DVD, but that depends on how much attention they pay to their
feed.
dinotrac
May 24, 2008
2:02 AM GMT TC -
If we're going to talk about straining and bending meaning --
Where do you come up with being unable to charge a fee that does not exceed
your cost of physically transferring the source, and, presuming that to be true,
what do you think that includes?
As I read the GPLV2, you may charge a fee for the physical transfer. The license
doesn't say that you can't make a profit in the transfer. It merely specifies
what the fee actually covers. You cannot charge for the source. Period. Not
even a penny. You can charge for the transfer.
jdixon
May 24, 2008
11:22 AM GMT As of yet, nobody's offered an intelligent reason
to believe the "community" is entitled to any special consideration beyond strict
compliance with the license.
Well, that's because we're not. And, like his method or not, Warren is now complying
with the license.
The only reason I have any problem with what he's doing is that I think it reflects
badly on my home area; and we have enough problems in that regard. That, of
course, is entirely a non-GPL issue (and not something I expect anyone else
to necessarily agree with).
Zenwalk, on the other hand, is a GPL issue. I've looked at the distro a few
times and even considered recommending it to people. This issue pretty much
shoots that idea.
tuxchick
May 24, 2008
11:49 AM GMT
dino, you're right, and azerthoth addressed that too. In the context of Mepis,
I am extra-critical because of Woodford's cruddy attitude and misinformation.
Yes, technically he's in compliance, but his whining and foot-dragging is bush
league. I bet if he had to buy DVDs every time he needed to update his own source
tree, or just a couple of applications, he'd complain plenty.
dumper, I believe in the spirit of a license as well as the strict letter. You
may recall Theo complaining how all these big commercial software companies
use and profit from BSD code, and don't give anything back.
Well, the BSD license permits that. But even so, I believe that for both
BSD and GPL code, that which is freely given should be received with gratitude,
and something given back. Instead of grudgingly following the rules to the least
extent possible- I think that is a slap in the face to all the contributors
whose hard work and talent make all this possible.
A GPL requirement could have a chilling effect on derivative distros
By Bruce Byfield on June 27,
2006 (8:00:00 AM)
Comments
Warren Woodford, the founder of the MEPIS
distribution, would prefer to be concentrating on polishing his latest release.
Instead, he is distracted by an official notice from the Free Software Foundation
that, because MEPIS has not previously supplied source code for the packages
already available from the distribution it is based on -- once Debian, and now
Ubuntu -- it is in violation of the GNU General Public License (GPL). Woodford
intends to comply, but he worries about how this requirement might affect all
distributions derived from other distributions -- especially those run by one
or two people in their spare time.
The requirement to supply source code is covered by section 3 of the
second version of the GPL.
Under these sections, the distributor of GPL code is obligated to provide source
code "on a medium customarily used for software interchange" for up to three
years. In practice, this medium is usually a CD or DVD, or a server from which
it can be downloaded. Under section 6 of the GPL, each distributor of the code
comes under the obligations specified in section 3. This obligation is specified
even more strongly in section 10 of the draft for the
third version of the GPL,
which specifically states that "downstream users" (those who, like Woodford,
adopt the work of another project -- the "upstream distributor" -- for their
own use) fall under these obligations.
"We think it's pretty clear," says David Turner, GPL compliance engineer
at the FSF. "One problem with allowing people to skip out on source code distribution
is that there's nothing that requires the upstream distributor to continue to
offer source code. If they stop doing so, the source could become totally unavailable.
Or, more commonly, the upstream distributor will upgrade the version of the
source code available, leaving downstream distributors totally out of sync.
In order to fix bugs, users need to get source code exactly corresponding to
the binaries they have available."
Woodford does supply the source code for MEPIS' reconfigured kernel in a
Debian source-package. His mistake seems to have been the assumption that, so
long as the source code was available somewhere, he did not have to provide
it himself if he hadn't modified it. While he has not contacted any other distributions,
he suspects that he is far from the only one to make this assumption. "We, like
10,000 other people, probably, believed we were covered by the safe harbor of
having an upstream distribution available online," Woodford says. "I think,
of the 500 distributions tracked by DistroWatch, probably 450 of them are in
trouble right now per this position."
A safe harbor is a legal term, referring to the elimination of the need to
comply because a violation was made in good faith.
Compliance in the community
Woodford is exaggerating, but not enough to change the basic truth of what
he says. Klaus Knopper, who develops the popular
Knoppix live CD, says that he maintains
a source repository and will make source code available on request. Talking
on behalf of CentOS, Johnny Hughes says,
"CentOS has been providing source for all packages, changed and unchanged, in
their distribution. CentOS has the same understanding of the GPL as expressed
by the FSF on this issue." Similarly, Texstar, the main maintainer for
PCLinuxOS, says, "I am aware
of the GPL requirements and make all of my source code available via DVD and
it can be downloaded from a free server."
However, a majority of distributions and their distributors are apparently
unaware of the requirements. "Before I was contacted by the FSF, I didn't know
that we needed to actually offer the source code of binaries we didn't modify,"
says John Andrews, the source code maintainer of
Damn Small Linux. "Yet we do comply
now, and the FSF occasionally pops in with an email to make sure we do." Similarly,
LinuxCD.org, a distributor, makes only
Fedora source code available -- and only provides that because it was specifically
requested to do so.
Unsurprisingly, no non-compliant distribution was willing to go on record
for this article. However, a search through the Web pages of two dozen randomly
selected smaller distributions in DistroWatch's top hundred shows only a few
download repositories that contain source code, and no offers to provide it
on request. The fact that only a few replied to a request for comments may also
be significant, suggesting that the maintainers, having become aware of their
non-compliance, do not wish to advertise their status -- although it might simply
be that, being small operations, they prefer to focus on their work rather than
answer questions. Still, even if Woodford's exact percentage is wrong, his suggestion
that the majority of distributions are unaware of the GPL requirements does
seem accurate.
Implications and solution-seeking
Woodford is now working to come into compliance. "Either I go along or go
to court with them about it, and it's a lot easier to go along," he says. "I'm
not making any money here. I can't afford a lawyer. I have an income, but I'm
just barely staying afloat. We're going to reply to their request, and it seems
like the request is consistent with the GPL license."
Woodford also understands that, while the FSF is firm about compliance, it
is showing restraint in its effort to get MEPIS to comply. "If we were a big
corporate entity, then they would ask us to pay them money," he says.
Yet, despite his willingness to comply, Woodford remains concerned about
the implications. According to Turner, because MEPIS distributes both online
and on CD and DVD, it would need to provide the source code in both media under
the third version of the GPL, although section 3b of the second version would
require distribution in only one medium. Woodford is also concerned about the
practical considerations of automating the regular extraction of only the packages
that MEPIS uses from the Ubuntu repositories.
Even more importantly, Woodford says, "I think that what they're doing is
probably going to be bad for creativity in the open source community. There's
plenty of people out there who like to be the GPL police. And with this extra
little thing in their bag of tricks, somebody is going to go out there looking
at everybody who puts out a new release of anything."
"What is really needed for the benefit of the community is if there could
be a way to have an exception for the little guy," Woodford says. "But how can
you do that when the whole thing is designed around the idea that every entity
and every person that uses the GPL is held to the exact same rules and standards?
How do you start making exceptions to that?"
Asked about the possibility of adding such an exception to the third version
of the GPL, Turner replied, "If someone submitted a comment to that effect,
we would of course consider that comment. But I don't think it likely that it
will be changed.... I just asked Richard Stallman about this. He noted that
the requirement isn't particularly onerous -- source code isn't much larger
than binaries."
Woodford, though, disagrees. "If I had been told this when I was getting
ready to create MEPIS in the first place, I never would have done it. I didn't
have a server, I didn't have a repository, and it would have been a daunting
task." His concern is that others will be similarly discouraged.
Andrews from Damn Small Linux also disagrees with Turner and Stallman, saying,
"I understand why the FSF makes sure small-time players comply with their requirements.
However, I also know from experience that it's quite a burden for the hobbyist
or small-time developer who wants to share something cool with the world but
doesn't have the finances or organizational structure of the big corporations."
"Of course, non-profit distributors can always arrange with their upstream
distributors to help them with the source code distribution," Turner suggests.
"If such an arrangement is in place, the problems mentioned above won't happen,
and the non-profit distributor will be able to save time and bandwidth."
Major upstream distributors, however, are unlikely to enter such arrangements,
if Fedora is any indication. Max Spevack, chair of the Fedora Board, says, "There
are several reasons why the Fedora Project would be hesitant to officially sanction
downstream distributions to point to upstream code repositories. The first has
to do with the issue of forking. If the downstream developer has improvements,
those improvements should be fed into the upstream code whenever possible. If
downstream doesn't want to push those changes upstream, then it makes sense
that the downstream distribution should bear the burden of redistributing the
source for the forked code.
"Second, there is an issue of legal liability," Spevack continues. "The upstream
party would be assuming legal liability for the downstream modifier, and that
is not something that the Fedora Project is interested in doing.
"The third issue is that of cost -- which, while a valid concern, in my opinion
is a lesser issue than the other two."
A possible solution for some distributions would be rPath's
rBuilder Online, a tool whose use
is free for non-commercial purposes and which allows users to build their own
distribution using a repository of the
Conary packaging system.
Since one of the points of a Conary repository is that it contains both source
and binary packages, using its version control system to keep track of them,
as Erik Troan, one of rPath's founder notes, using "rBuilder automatically solves
the problem by providing permanent access to binaries and the sources." Distributions
based on rBuilder would still need to maintain their own repositories, but would
not need to set up separate source repositories. This is the solution that
Foresight Linux has chosen. However,
rBuilder Online is not available to commercial distributions, and Conary is
still a new and relatively unknown packaging system.
Many derivative distributions, then, seem to be on their own in a difficult
situation where good intentions and creativity count for nothing beside the
letter of the law.
For Woodford, the situation means struggling for compliance while preparing
his next release, and the strain of the additional concerns is taking its toll.
"I'm just trying to get back to the point where I can sleep at night," Woodford
says. "Last night, I went to bed at 1:30 and just lay in bed thinking of all
the technicalities that have been discussed about the GPL and how I'm going
to access the source and make it available."
Bruce Byfield is a course designer and instructor, and a computer journalist
who writes regularly for NewsForge, Linux.com and IT Manager's Journal.
Bruce Byfield is a computer journalist who writes regularly for Linux.com.
Re:Play by the rules, plain and simple
Posted by: Anonymous Coward on June 28, 2006 07:09 AM
If I were a small distro, I would make it available by request as a DVD,
and charge shipping and handling fee's. In other words, if it took me 30 minutes
to make the DVD, I should be paid for that time, plus the cost of the media,
plus the shipping fee's. Many of these small distro's are operating on virtually
nothing, they deserved to be paid fairly for providing the source code!
#
Re:Play by the rules, plain and simple
Posted by: Anonymous Coward on June 28, 2006 07:08 PM
I agree. Charge US$100 plus shipping costs for sending the source code on
CD or DVD and everybody's fine.
#
Re:Play by the rules, plain and simple
Posted by: Anonymous Coward on June 28, 2006 10:16 PM
The paretn post is almost legal by teh GPL the post above is not at all.
You may only charge teh cost of shipping and medium for requested GPL software,
wherr the you are usinga physical medium. This is the method chosen by one distributer.
#
Re:Play by the rules, plain and simple
Posted by: Anonymous Coward on June 29, 2006 04:51 AM
According to a copy of the GPL, the paragraph says:
"b) Accompany it with a written offer, valid for at least three years, to give
any third party, for a charge no more than your cost of physically performing
source distribution, a complete machine-readable copy of the corresponding source
code, to be distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,"
Emphasis added by me. Whether US$100 reflect my costs to physically perform
the source distribution is a matter of calculation and the current circumstances.
Please note that some people may never pay, I may need to buy a CD burner to
burn the disc, it will take some work to prepare the disc depending on how the
original sources are stored, there's packaging, fees, maybe taxes, you need
something to track the money, telephone calls, etc.
I don't know whether US$100 are a good guess. It might be less, it might be
more. That probably also depends on where you live.
Re:Play by the rules, plain and simple
Posted by: Anonymous Coward on June 29, 2006 04:51 AM
According to a copy of the GPL, the paragraph says:
"b) Accompany it with a written offer, valid for at least three years, to give
any third party, for a charge no more than your cost of physically performing
source distribution, a complete machine-readable copy of the corresponding source
code, to be distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,"
Emphasis added by me. Whether US$100 reflect my costs to physically perform
the source distribution is a matter of calculation and the current circumstances.
Please note that some people may never pay, I may need to buy a CD burner to
burn the disc, it will take some work to prepare the disc depending on how the
original sources are stored, there's packaging, fees, maybe taxes, you need
something to track the money, telephone calls, etc.
I don't know whether US$100 are a good guess. It might be less, it might be
more. That probably also depends on where you live.
I am not an attorney. This is not legal advice.
-- Warren
Q1. What is this GPL license all about?
A1. The GPL license and the Free Software Foundation make sense to me if
I assume that the purpose of the GPL license is to force the redistribution
of all source code and to prevent commerce that does not include the
unencumbered redistribution of all source code. The FSF recommends that
you assign your copyrights to them, so they can insure your software "freedom."
If the FSF succeeds, all source code will be GPL licensed and controlled by
the Free Software Foundation; and all Laws regarding software patents and copyrights
will be rendered ineffective.
Q2. Why would anyone want the GPLed source code in MEPIS?
A2. Except for a few packages, the sources are available at the Ubuntu and
Debian repositories. The MEPIS kernel source is available from the MEPIS repository.
So there is no obvious reason for anyone to want to get the MEPIS related GPLed
source code from MEPIS, except to verify that MEPIS is complying with the GPL
license restrictions.
Q3. Who is required to distribute GPL licensed source code?
A3. According to the GPLv2 license, any party who causes a party to receive
GPL licensed binary code is required to make available to that party a copy
of the source code, if the other party requests it. It doesn't matter whether
you have ever previously had or wanted a copy of the source code, you are required
to have a copy so you can redistribute it.
Q4. Does this mean that if I give a copy of MEPIS to a friend, I also
have to give them a copy of the GPLed source code?
A4. According to the Free Software Foundation, if they want the source code,
it means exactly that. Whether you give MEPIS to a friend or install it on a
computer and sell it, or even if you give it away on the street corner, you
are still obligated by the restrictions of the GPL license.
Q5. I want to distribute MEPIS to others. How can I do that and meet the
legal restrictions of the GPL license?
A5. MEPIS offers the source code in compliance with the GPL license restrictions.
If you have an agency relationship with MEPIS, then you are not distributing
MEPIS independently, and therefore you are not independently obligated by the
GPL license.
Q6. How can I have an agency relationship with MEPIS so I can give away
copies of MEPIS Linux?
A6. Only for the purpose of satisfying the restriction of the GPL license
regarding GPLed source code, MEPIS hereby grants an automatic limited agency
relationship to individuals and groups giving MEPIS CDs to others free of charge
or for a fee that is charged only to raise funds for a legal not-for-profit
activity. This includes individuals giving copies to friends, Linux User Groups,
the KDE Project, the Debian Project, Ubuntu, and other not-for-profit entities.
This relationship is not granted to for-profit entities and this relationship
is not granted in jurisdictions where MEPIS is prohibited by applicable Law
from distributing MEPIS, specifically the "T6" and the "restricted strong encryption"
countries.
Q7. How can you charge for the source code? Isn't it suppose to be free?
A7. The "Free" in Free Software Foundation is not about price. It's about
who controls the source code. The FSF has created a non-standard definition
of the phrase "free software." See A1.
Q8. I'm not sure if my situation is covered by the other answers, what
should I do?
A8. Contact MEPIS via info@mepis.org and explain your situation.
December 12th, 2008 | howsoftwareisbuilt.com
Interview with Warren Woodford - Founder of Mepis
Interviewers:
Scott Swigart
and Sean Campbell
Interviewee:
Warren Woodford
In this interview we talk with Warren. In specific, we talk about:
Sean Campbell: Warren, could you introduce yourself and tell us about
some of the things you have worked on during your career?
Warren Woodford: Sure. I’ve been pushing electrons for a very long
time. I grew up with what is now the computer industry, and I was already working
at almost the VP level when the first microcomputers came along.
My background includes telecommunications, entertainment, field service,
mini computers, micro computers, mainframe computers, PCs before they were called
PCs, real time processing systems, software for business, software for home,
software for government, and tools that people have heard of if they’ve been
around a long time–always on the bleeding edge.
That’s the way I worked until the Internet bubble burst, at which time I
kind of withdrew and decided to take it easy while the economy was down, not
realizing it was going to be so volatile for so long. It was in 2000 or 2001
that I first started looking at Linux.
Aside from the philosophy and technical foundations of Linux, there was a
lot there that I really didn’t like, frankly. Because of my background, I had
been a champion of GUI interfaces since the early ’80s, and that aspect in particular
was very inadequate at the time.
The bottom line is that, when I first found Linux, it was too rough around
the edges for me. That represented the possibility of opportunity, not that
I was really looking for work. This will piss off a few people, but there was
a certain amateur quality about it.
Around 2001 was the first time I used a version of Linux that felt pretty
good, which was SUSE, but it also had some significant bugs. It was pretty mature,
but it was stiff–just too rigid in the way it did certain things. Mandrake seemed
like it was on the right track, but there were bugs in the installation process
and things like that.
Still, I felt that there was promise, so I started using Mandrake around
2001, and as I got familiar with everything, I decided that it was marginally
good enough. Then, in 2002, Mandrake stumbled badly with their release in the
September/October timeframe. They made some big mistakes, in part because of
pure hubris.
It was around that point that I started thinking about building a version
of Linux, instead of depending on other people. I jumped into it, deciding to
pursue it as a way to learn technology that I didn’t know.
It has always turned out that when I learn a new technology, opportunities
arise, whether my original reason for getting involved worked out or not. That’s
how I got into Linux and decided to develop MEPIS. It was first for myself,
and then I decided to see what would happen if I gave it free reign.
It got picked up by Distrowatch and went to #10 in one month, and that told
me something. I started spending almost all of my time on it, but then in 2004
I had an injury that laid me up for a long, long time. During that time, MEPIS
made it to #1 at Distrowatch, but I couldn’t really do much to maintain it.
Then it slid. Mark Shuttleworth saw opportunity and forked Ubuntu off of
Debian. To be clear, I think that has ultimately been good for Debian, and Ubuntu
contributes a lot back to the Debian community, but it is clearly a fork.
Sean: What do you think about Ubuntu’s strategy? They contribute upstream–more
as of late, in fact–but at the same they time fuzz the distinction for users
that Linux is really a collection of sub projects that are traveling in the
same direction at roughly the same velocity.
I actually think what he’s trying to do isn’t all that bad, but I may have
the luxury of some detached pragmatism. I see it as a logical, commercially
driven decision, but I’m curious what you think about it, because you’ve obviously
got a lot more history in this than I do.
Warren: I’m not bothered by anything that Ubuntu does. I think that
Ubuntu pushes the boundaries regarding purity, and I don’t think that’s a bad
thing, although that gets me in trouble with some people.
Some people call me a whiner about the GPL, while from my point of view they
are the whiners. The GPL deserves to be scrutinized closely and to be debated,
as does any legal document that restricts people’s rights. Calling a person
a whiner because they care enough to challenge, question, or state positions
about something is itself whining.
I think it’s good that Ubuntu challenges the boundaries regarding what is
and is not proper open source. I think that what Ubuntu contributes back, both
upstream and cross-stream to Debian, is good. And I think that the way that
they kicked Debian in the collective butt has been good for Debian.
The fact that Mark is out there trying to make commercial deals actually
may or may not make a big difference in the long run, but it’s not necessarily
a bad thing. For example, I know that a couple of years ago he negotiated with
IBM to get Ubuntu approved as a platform for running DB2. That would make it
very easy to get that DB2 approval extended to Debian if anybody wanted to,
and I think that’s OK.
From the point of view of what’s right and wrong, I don’t think there’s anything
at all wrong with their fuzzying things a bit, as long as they don’t do it as
much as Xandros did. Xandros at one point was blatantly changing copyright,
renaming things and such, to make it appear that they had invented KDE or something.
I can’t speak for what was in their mind, but something was going on there.
I don’t see Ubuntu doing that. I see them creating projects of their own
to build utilities that represent their philosophy about how such things should
be done, like the Adept project for a package manager. However if there’s a
good product out there already, then there’s no good reason for them to be reinventing
the wheel.
I think KPackage has been kind of so-so. On the other hand, I think Synaptic
is awfully darn good. But Synaptic is GTK based, and while that’s not necessarily
a bad thing, I wouldn’t program in that world. For personal reasons, it would
be too inefficient and take too long to do. I wouldn’t program in Python for
the same reason.
I don’t see anything wrong with creating or sponsoring Adept, just as I don’t
see anything wrong with the idea of starting Ubuntu in the first place. You
can complain or you can say that competition’s a good thing.
Mark, for one, is probably not going to pursue something unless there really
is a shortcoming to be addressed.
Sean: What about Ubuntu’s OEM strategy? They have done really solid
work in getting Toshiba to push Ubuntu, for example, and of course they also
have Dell with five systems. They seem to be doing a really bang up job in getting
OEMs to ship, promote, and push the Linux based desktop, and that doesn’t even
count the netbooks push that’s happening.
Do you think they may have figured out a strategy that could give them a
certain position on desktops that others haven’t quite figured out yet?
Warren: An important consideration is that Mark is more or less a
billionaire, and he made that money in the computer industry. He can talk to
companies like Dell, IBM, Toshiba, and others with a level of credibility that
no one else in the Linux industry that I’m aware of can match.
He can get in the door to propose things, and he can get things agreed to
that nobody else can. That gives him an advantage when you consider one distro
over another, but that’s just how things are.
That’s good for Linux as a whole, and it means that companies like Dell and
Toshiba are starting to think about compatibility more than they were before.
And that’s a good thing. There are people who have told me, “Hey, this is really
great. I bought a Dell machine with Ubuntu and then put SimplyMEPIS on it and
it all worked.”
Sean: You’ve got Intel producing video drivers and wireless drivers
and you’ve got network managers, so this is where the Ubuntu fuzzing works both
for and against you. On the one hand, it makes the user feel like the network
manager is Ubuntu’s network manager, even though it isn’t, really. On the other
hand, they can just go stick a different distro on it.
Warren: Yes. In that regard, they’re having a positive impact on Linux
compatibility with mainstream hardware, by getting the mainstream hardware companies
to think a little bit about compatibility.
Scott Swigart: How much difference is there, from an application developer’s
perspective, between different Linux distros? And how much work is that to take
into account, and how much does something like the Linux Standard Base help
with that?
To put it another way, for an application developer, how much effort is it
to support and test and ensure that you’re compatible with lots of different
Linux distributions? And how much of that work is done by the app developer
versus the distros themselves?
Warren: That is a very big question. About three years ago, some of
the biggest companies in the computer industry brought together some Debian
affiliated companies like mine regarding this very question. They wanted to
explore having Debian-based Linux as a competitor for Red Hat and Novell, and
it gave rise to the ill-fated Debian Common Core Consortium.
Those conversations arose from this very issue. You couldn’t have commercial
applications or commercial support for a particular Linux distro without a known,
stable base. That plays out at different levels, because it depends on what
kind of application it is. If it’s something for server, then probably, you
only care about a core set of packages.
You can have a core set of packages, and you can have standards around that.
If you do, then at the very lowest foundational level, companies that are considering
something commercial related to Linux have a common base that they can rely
on. But what’s the real core if you’re running a practical application?
And if we’re not using straight X, then what toolkit are you using, and what
version? Consider the case of Acrobat Reader for Linux. How are you going to
release Acrobat Reader in a way that runs cross distro, when each distro and
each release of each distro may have different versions of key libraries?
Adobe does it by basically bundling those libraries, so they only have to
rely on the very minimum number of compatible packages, or libraries, on a particular
release.
From the point of view of an application developer, the problem is that every
distro and every release of every distro has variations in what versions of
core packages are installed. And because each distro has a different philosophy
about long term maintainability and about stability of the distro, it’s a moving
target forever.
You know, it’s a miracle that Firefox works so wonderfully. Those guys are
incredible, and so are the Open Office people. Figuring out how to write code
that is compatible with so many different versions of libraries to run with
or be compiled against is a huge job. This is where Linux has a really big disadvantage
when it comes to building complicated applications that you want to distribute
broadly.
Scott: Educate me on the Linux Standard Base. What you basically said
is that it’s a moving target forever. How much does the Linux Standard Base
do to alleviate that? It feels kind of like POSIX back in the day.
Warren: In my opinion, LSB doesn’t do a lot for that. LSB provides
some value, like POSIX provides some value, but it doesn’t resolve all the issues.
New releases of MEPIS are still on top of Debian, which acts like a stable
core or foundation on which MEPIS is built. If you take the latest version of
OpenOffice and recompile it for Debian Lenny, OpenOffice 3.0 will compile in
that environment. But OpenOffice 3.0 will not compile on top of Etch, because
so many things have changed. One of the things that happens is that a lot of
libraries change over time–names of libraries, APIs, and entire philosophies
change.
Underneath it all, Linux represents a very active developer community in
various areas with people trying out new ideas or making improvements. Without
them being coordinated with or accountable to projects like OpenOffice, or Firefox
or whomever, it’s a real challenge to build a stable distro or to build a complex
application and have it be compatible.
Scott: There seems to be a lot of pressure as companies become more
comfortable with Linux, to move from the paid distributions to the free ones,
because they find that they’re not picking up the phone. They are not making
a lot of support calls and things like that.
On the other hand, if we are at conference and we walk up to the Red Hat
booth and ask them about that, their response is typically that the Linux market
overall is growing, and it’s only going to be a small percentage of the total
number of Linux users that go from free to fee. They are just happy to see the
overall market grow.
Warren: In general, corporate America wants something that is supported
officially. You can argue about why that is, and it may be a bit cynical to
say so, but my impression is that people in companies can’t afford to take the
chance of guaranteeing something themselves.
You are in a company and you are working toward retirement. You have a good
job with benefits, and you do not want to say, “Well, let’s use this free version
of Linux. I guarantee you it will be fine, and we will take care of any problems
that come up.”
People don’t want to do that in the corporate world. They want say, “Well,
Gartner says this thing over here is great and will work fine for our purposes.
They have an annual support contract, and they’re an established company, so
we can go with this.” The company can feel comfortable, and everybody up the
food chain can be held blameless if something goes wrong.
I think that is the number one driving factor for free versions of Linux
not being used in corporate America, except covertly or in very special circumstances
where management is used to taking risks. Some industries are more risk-averse
than others, of course.
The commercial versions of Linux also offer extras that the free versions
don’t. If you look at Red Hat versus Fedora or Novell versus SUSE, they are
offering extra things, like guaranteed update schedules, tiered support, and
other kinds of extras. For example, their versions also contain extra utilities
that facilitate and manage enterprise deployment of Linux.
Now, a small company can sure start out with Red Hat and switch to Fedora,
and in a ten-person company with a good technical person in house, that could
work out fine. For the most part, though, that won’t happen in larger companies
except where risk taking is the norm.
Scott: Do you see that changing over the next five years or so? Do
you see some of those larger, somewhat risk-averse companies realizing that
there is money that they could be saving by not writing a big check every year,
if they haven’t been having the problems they were worried about?
Warren: They absolutely will consider writing a smaller check to a
different company, but I don’t see them going with something that is completely
free and open source unless it is not critical to their operations.
I know of a recent scenario where a company had no approved product for doing
a translation; if I remember correctly, it was a transform between PDF and TIFF.
They couldn’t find a commercial product that exactly met their requirements
and was approved by their enterprise architecture organization.
Since they couldn’t get enterprise architecture to suggest a product, they
went with something open source. But that’s a minor usage of an open source
product. I guarantee that same company won’t use Linux as a platform OS. They
hang their hat on IBM big iron and AIX.
In the corporate world, it’s largely not a matter of writing a check or not–it’s
more writing a big check versus a smaller one, where the person championing
it to upper management isn’t going to get hung if something doesn’t work.
People will be bothered if there’s a big problem with some software, but
if the company is big enough and proper due diligence was done, then nobody
is going to be fired if it doesn’t work out.
Scott: What about the year of the Linux desktop?
Warren: It’s never going to happen. Sorry.
Scott: Why not?
Warren: There’s a chicken and egg problem with getting it on the desktops,
where no matter how much Mark Shuttleworth does, Michael Dell is not going to
tell Bill Gates where to go. No one is going to forget that Microsoft’s the
big game in town, no matter how much Microsoft stumbles.
Mark Shuttleworth can spend his entire billion dollars on trying to make
Ubuntu good enough to shoot down Microsoft on the desktop and that won’t change.
It goes back to what I was saying earlier about the fragmentation in the Linux
market.
You don’t have one set of products against which you can build commercial
software, or do commercial deployment, or even long term enterprise deployment.
It’s doable with Ubuntu, but it’s not a no brainer, although Novell and Red
Hat are trying to address that part.
Right now, I don’t know of a single major corporation that would go with
Linux on the desktop for one reason–no Visio. Until OpenOffice does a Visio
clone, you can forget it.
Sean: That reminds me of a story. Wikipedia went to Ubuntu recently
for all their servers, but they still have one Windows machine to run QuickBooks,
which runs their financials.
There’s the problem, right? And it leads to the question, if you were king
for a day, what is a reasonable goal for Linux on the desktop?
Is it netbooks, where because it can be thin and light, it’s kind of a doorway
to the Internet? And then if you want to leverage all those other locally installed
apps, you have to go over to the Windows thick client? That scenario is a bit
like the way Apple is carving out a niche with a certain set of consumers.
Warren: Like I said, Linux desktops cannot win in big business as
long as there is no Visio clone. They can’t win in small business because of
the very thing you mentioned–QuickBooks. Small companies all seem to use it.
On the other hand, some things that are happening right now, like Nokia buying
Trolltech and Google inventing Android, can shed light on where the opportunity
lies.
In other words, appliances are a place where Linux, with a GUI, can land
and really thrive in my opinion–not the desktop we’d normally think of.
Scott: We talked to someone from Mandriva, and his impression was
that by focusing on the Linux desktop, people are missing the boat. He suggests
that Linux is going to bypass the desktop altogether, because people are looking
for the day when won’t need their laptop on the road, because they have a phone
and similar devices that are sufficiently capable.
So Linux is not well suited for the desktop, as we know it, but it might
be very well suited for what comes after the desktop. Even if the desktop always
remains as a mainline use case, there are going to be other scenarios with handheld
devices.
Linux shouldn’t really be aiming at where people have been, it should be
aiming at where they’re going, and it might be better suited for that.
Warren: I think that’s exactly where it is going, and it is happening
right now, specifically with things like Android and Nokia. Notice that in the
handheld arena, you don’t probably want QuickBooks or Visio.
Because these application markets are just getting established, if you make
sure that the environments support the major toolkits for developing applications
for those environments, you’re not going to fall short.
To touch back on Linux on the conventional desktop, though, I use MEPIS for
everything I do. I just spent a year on site in a corporate environment, and
I used MEPIS everyday.
Almost everybody there was using Windows, but my Citrix connections were
better, and so was my wireless connection within the corporate environment.
Through Citrix, I was able to use Microsoft apps. An individual can absolutely
use Linux for their desktop and have very little that they’re falling short
on.
I also run all kinds of things in Virtual Box. Actually, for MEPIS, I do
a recompile of the open source Virtual Box, because since Sun took over, they’ve
been a little behind on recompiling the open source edition. If you’re using
a 2.6.26 or a 2.6.27 kernel, you can’t run a guest on Virtual Box unless you
have Virtual Box Version 2.0.2 or better.
The bottom line is that I can run Windows in Virtual Box, and I can run all
kinds of test scenarios in Virtual Box. I can run from whichever 32 or 64 bit
version of MEPIS I want. My main development machine is a MacPro, so I can even
run OS X when I need to do that. It gives me one heck of an environment as a
developer.
Scott: I want to be sensitive to the time, so is there anything you
want to add in closing?
Warren: Earlier you asked about what I thought was not given as much
attention as perhaps it might be. To follow up on that, there are reasons for
DNSSEC and IPv6, for example, to be implemented and used.
The circles that I run in, I haven’t heard much talk about DNSSEC or IPv6,
except very recently. I think that with IPv4 running out of IP addresses, IPv6
has to come along really soon. But the problem is infrastructure not OSes; I
think most Linuxes can do IPv6 out of the box. MEPIS certainly does.
DNSSEC, though, has been with us for 16 years now as a concept, and it hasn’t
been implemented. It should greatly improve security on the Internet regarding
spoofing and things like that, and there’s work being done to actually implement
it now. Still, though, I don’t hear much being said about it, and I don’t know
to what degree people are getting ready for it or considering implementing it
sooner rather than later.
The .gov domain is going to start implementing DNSSEC January 1st. There
are trials that have been done, I believe, for .com and .org, but if you look
to see what’s been done regarding integrating DNSSEC in user applications, there’s
practically nothing.
It’s all at the experimental stage. To go to a website and be able to identify
immediately that it does not have a valid DNS record would be a great thing.
That’s something that I would hope that the Firefox project is going to put
in the next release, but I don’t know that they are.
Sean: Those are great points. Thanks for taking the time to talk today.
Warren: Thank you.
[Apr 30, 2009] Is Xming Another Example of Misunderstanding Libre Licenses?
Another rabid "libre" defender. Pretty annoying and narrow minded...
Wed, 2007-11-14 04:13 — dcp
Xming appears to be a useful program for accessing and running your GNU/Linux
applications remotely from a Windows computer. It is licensed under the GPLv2.
But just how free is it, really?
Xming looks like
a great tool for connecting Windows boxes to remote GNU/Linux computers to run
applications. And, according to the license included with the software, it is
released under the terms of the LGPLv2. Unfortunately, the developer's website
includes a strange notice that poses a potentially confusing challenge for those
who wish to redistribute the software. In addition to the GNU GPL license, the
author requires that anyone desiring to redistribute the software must ask permission
to do so.
According to the 3rd paragraph (displayed according to "fair use", as allowed
by U.S. copyright law):
Xming is mostly a derivative work with many component licenses e.g.
the zlib license, LGPLv2 for Pthreads, MIT/X11 for all PuTTY tools and the
Pixman library, or Creative Commons by-nc-sa. Redistributing any part (or
whole) of the Xming website, documentation, images, executables or installers,
by the internet, other projects/products or via media such as CD's, without
asking permission, attributing 'Colin Harrison' and providing links to
http://StraightRunning.com/XmingNotes/ and SourceForge Project Xming
will be regarded as a breach of copyright.
Note that the statement, as it currently reads, states quite clearly that
the program is derived from several others, including software licensed under
the GNU LGPLv2. The statement then refers to redistributing any part (or
whole). Taken as is, the statement appears to cover the upstream code licensed
under the terms of the LGPLv2 - in violation of that license's Section 10. Whether
this is what Colin Harrison, the Xming developer intends is another question.
When Blue GNU contacted Harrison seeking clarification, his initial response
was that if I don't like the license, I don't have to use the software. When
I clarified that I was not attempting to engage in a debate, he replied that,
"I don't have the time to explain my licensing at the moment. When the dust
settles on the GPLv3 debate I will clarify the situation more in Xming." Meanwhile,
the statement leads to possible confusion now, and downstream users need to
be clear as to what is covered and what is not.
Harrison did take time to complain "that most of the software I have written
in the past for free is now embedded in devices and products that I don't have
source access to, or even change feedback or attribution." He did not specify
whether he thought any of these uses were in violation of his license, or whether
he has made any effort to enforce his license in such cases. He went on to further
complain about "freeloaders" who do not give "attribution" without being more
specific.
Harrison's e-mail ended with a question about whether FOSS might be devaluing
the expertise of professional developers. Blue GNU has replied further saying
that clarification of the statement on the website is needed, since Xming may
be violating the LGPLv2 under which Pthreads is distributed by adding further
restrictions on the software (section 10 of the LGPLv2) and failing to make
the source code available. No source code for Pthreads is available from the
Xming site, nor included in the distribution. Blue GNU also contacted the
Win32 Pthreads developers and the FSF to
find out if they agree there might be a violation.
Harrison's stipulation that redistributed copies of Xming must include links
back to his own project appear hypocritical in view of the fact that he does
not link back to the projects mentioned in the same paragraph. And, while it
might withstand scrutiny in court, the stipulation amounts to a sort of advertising
clause - something that has always been considered problematic. Perhaps this
could have been better resolved through a trademark?
Neither Colin Harrison, the Pthreads developers, nor the FSF have had time
to respond to the latest e-mails, so it remains to be seen how the issue will
play out. However, the situation does raise some serious questions about how
well developers understand Free Software licenses.
- How well do developers understand the various licenses they choose to
use?
- Do they even bother to read them, or do they simply choose them because
they're canned legalese?
- How well do people really understand that Free Software, according to
the Free Software Definition and other documents, must be
free to distribute
and use commercially (for any purpose)?
- Do developers understand that a company, an individual - anyone - can
modify Free Software in-house, and never give back so much as a comment,
as long as they do not redistribute the modified version?
- Can a developer release something under a given license, and then still
require explicit permission to redistribute it, or does meeting the license
requirements satisfy copyright law?
- How does one define "attribution"? If all the copyright notices are
intact, is that not attribution? Or must a project necessarily advertise
for its upstream project(s) in order to be considered to be "attributing"?
Developers and others might modify and/or redistribute Free Software should
always undertake to read and understand any licenses for code they choose to
modify and/or redistribute, so they can ensure compliance. They also need to
be clear when imposing additional stipulations that may involve code others
have developed, as to exactly what is, and what is not, covered. While the issue
can very likely be resolved fairly quickly and with little fanfare, developers
could save themselves a little time and a lot of stress by doing some research
and communicating clearly from the beginning.
Note: As of 14:25-14:30 GMT-5, the Xming site is returning a time-out
error.
Note: Warren Woodford ran
into problems when notified by the FSF that he must provide the source code
for his Mepis distribution.
All my software on SourceForge is PublicDomain. Do with it what you want, or
shove it. I have explained the minor error I made on my site and elsewhere.
Walk away Parris, stop trolling now.
Sat, 2007-11-17 17:36 — ColinHarrison
Having failed to troll me on my own Xming Forum Parris appears to have forced
me to troll his. Xming is no longer licensed GPL, it is a derivative work with
many licenses none of which is GPL, except for the legal use of one LGPL library.
As I said to him if you don't like the license don't use it. That statement
appears to have started World War three. I suppose you could not expect anything
better from an 'Absolute Truth' merchant like him, so we all have to suffer
defamation at his hands.
Both the fsf and the maintainer of Pthreads-Win32 have not given me the thumbs
down as described by Parris here. And yes I have wasted lots of time on this,
and yes I have corrected some minor licensing anomalies in Xming.Again "Parris
don't use anything you don't want to" and I'm not a blue-GNU supporter (or can
be converted and baptised as one for your gratification)
BTW I have no objection to developng GNU/FSF software, but if it could ever
be used by people like Parris, perhaps I should :)
Colin Harrison
http://www.straightrunning.com/XmingNotes/
http://sourceforge.net/projects/xming
LGPL version
2
From this blog for January
8 2008:
What’s worst about [the hate mail I get when ever I comment on SCO] ,
however, is that the “groklaw effect” has become a significant component
in the overall Linux “gestalt” - and just about everything most of that
mob has been led to believe about the case is wrong.
The fundamentals of the case are simple: SCO (and I use the name generically)
asked IBM to pay continuing royalties under its AT&T Unix licenses; IBM
said words to the effect of “Nope, we have a fully paid perpetual license”;
a discussion ensued during which SCO became convinced that IBM had breached
the contracts by allowing people with intimate knowledge of the AT&T source
to contribute to Linux; and so SCO issued the 90 day license suspension
warning against AIX required under that contract.
At the time I expected that IBM’s senior management would review the
issue, recognize a problem, and settle expeditiously with SCO; but that
didn’t happen. Instead IBM circled the wagons and waited for SCO to do what
it had to under the contract: escalate the conflict by formally suspending
IBM’s Unix licenses with respect to AIX and then ask a court to enforce
that order against IBM.
That should have been a simple process: all SCO had to do was show the
court that at least some IBM Linux contributors had significant prior or
concurrent exposure to AIX source and it would have been game over for IBM.
That didn’t happen either: instead it appears that someone somewhere in
the process saw the combination of IBM’s intransigence and deep pockets
with a rather obvious contractual dispute as a potential gold mine - and
out of that we get the next act in which a major east coast firm, headed
by the same lawyer who had been unable to prove that Microsoft benefited
from an illegally obtained and enforced monopoly, gets a cost plus style
contingency agreement to prosecute the case against IBM and we start to
see inflammatory, and largely incorrect, claims issued in SCO’s name.
Re: Does Cringley even follow the SCO lawsuit
anonymous-insider on 04/06/2009 at 7:48 PM
Groklaw's anti-SCO efforts began in 2003 at
http://radio.weblogs.com/0120124/
as a PR campaign by Pamela Jones for her company Medabiliti Software Inc.
Medabiliti Software Inc had just written for Exemplar International -known today
as Examinetics- a Web application named XM Network. XM Network run on Linux
and was written on open source software.
Medabiliti Software Inc needed a PR campaign to convince its clients, including
Exemplar International, SCO's suit against IBM had no merits. A timeline of
Medabiliti Software is found at
http://tinyurl.com/djp8lj
.
Originally, Groklaw was Medabiliti Software's vehicle for that campaign.
While Medabiliti Software ceased operations in 2004, Groklaw's private agenda
continues to be a PR campaign against SCO.
Re: Does Cringley even follow the SCO lawsuit
anonymous-insider on 04/07/2009 at 1:33 PM
Pamela Jones began to write at
http://radio.weblogs.com/0120124/
.
Later in 2003, she stopped writing at
http://radio.weblogs.com/0120124/
and moved to http://www.groklaw.net/
. See the note 'We Have Moved Permanently' at
http://radio.weblogs.com/0120124/
.
Some of Pamela Jones writings were factually wrong due to her anti-SCO agenda.
The article 'And They Call Linus Careless' found at
http://www.groklaw.net/articlebasic.php?story=66
is an example of such a writing.
Linus Torvalds was indeed careless on Linux kernel source code management. See
the paper 'Kernel comparison: Improvements in kernel development from 2.4 to
2.6' at
http://www.ibm.com/developerworks/linux/library/l-dev26/ .
Groklaw is mainly read by fanatics that blindly follow Pamela Jones' agenda.
Still, you're welcome to draw your own conclusions with content found at
http://tinyurl.com/c4ypfg
and http://tinyurl.com/cy8mcz
Re: Anonymous Insider
anonymous-insider on 04/10/2009 at 12:47 PM |
In regard to Kimbal, I'll use the same words written by Paul Murphy:
"So here’s a bet - and if you want to accept the bet just put a note to that
effect in the comments here. If this court [
http://www.tmcnet.com/usubmit/2009/03/07/4038711.htm ] or one directed by
it does not overturn Judge Kimbal’s ruling and I’m still writing this blog [
http://anonymous-insider.blogspot.com/
] the week after it happens, I will dedicate a Saturday entry entirely to lines
that look like this: Dear XX - I’m sorry, I was wrong about the appeal court’s
response on SCO’s ownership of the copyrights."
See http://blogs.zdnet.com/Murphy/?p=1562
Groklaw's intent to influence Kimbal's decision is clear.
See
http://www.krsaborio.net/research/linux/related/groklaw.htm
Then, the speculation on Solaris 8 source code and methods on Linux arises on
how easy it was for Linux kernel developers to obtain third party source code.
See
http://www.krsaborio.net/research/2000s/02/0331.htm
As Paul Murphy said, "the corpse is still twitching". The corpse might go to
court again...
Finally, you'll find a note by Pamela Jones at
http://www.groklaw.net/newsitems.php
about Cringely's article:
"[PJ: For what it's worth, my guess is that SCO has absolutely nothing to do
with it. For one thing, while Cringely says "some mingling" has taken place,
the allegations SCO has still on the table are essentially none.
Here's what SCO and IBM each filed, telling the judge what each believes
survived the
decision in SCO v. Novell that Novell owns the copyrights and that
Novell has the right to tell SCO not to sue IBM. Unless SCO is able to overturn
that decision on appeal and then win before a jury after a trial, which I consider
unlikely, personally, there is nothing dogging IBM about any SCO allegations
about copyrights. Even if that could happen, and SCO were named the owner of
the copyrights, the code that SCO finally presented before the court's ruling
was more or less nothing at all, with multiple defenses at hand even if they
were not laughed out of court, to the extent they were known publicly. So whatever
the proposed deal was about, I don't believe IBM is worried about SCO v.
IBM. And the fact that IBM apparently just walked away from the deal indicates
whether I am right in my supposings or not.]"
That's the note that sent me here.
Your original pro-Groklaw comment motivated me to argue with you.
Ciao.
IBM's future is indeed tied to Sun's acquisition
anonymous-insider on 04/06/2009 at 4:28 PM
Recently, Rob Enderle wrote:
"There is some speculation that Solaris is
the source of many of the core components in the current generations of
Linux, and that IBM's acquisition could prevent another SCO event in the
future, should someone less friendly acquire Sun instead."
See http://tinyurl.com/dz6gza
Some of the rationale behind the speculation has been exposed at http://tinyurl.com/c9nzuu
(see comments in the bottom of the main article). If the speculation proves
correct, IBM will have to pay Sun's asking price.
Re: IBM's future is indeed tied to Sun's acquisition
anonymous-insider on 04/07/2009 at 1:43 PM
I welcome you to obtain a copy of Solaris 8 source code as it was released
by Sun in late 2000. See http://tinyurl.com/cbedk3
Solaris 8 source code was available for download on the Web until sometime
in 2002. There might be some copies at MIT.
Then compare against Linux kernel versions 2.4.17 and later, all 2.5 tests
and early 2.6 versions.
Do your comparisons in the following kernel areas: task scheduling, virtual
memory management (VM), communication device drivers, TCP/IP, storage device
drivers, web server, kernel locking, kernel preemptibility (SMP only), buffer
cache management, IPC (semaphores, shared memory, message queues, and pipes).
Re: IBM's future is indeed tied to Sun's acquisition
anonymous-insider on 04/07/2009 at 5:35 PM
"... there is no PROOF that PJ ever worked for Medabiliti Software..."
That was exactly Medabiliti Software's strategy.
For better 'credibility' on its PR campaign against SCO, Medabiliti Software
needed to distance itself from Groklaw.
There are a few bytes of information that relates Pamela Jones of Groklaw
to Pamela Jones of Medabiliti. See http://tinyurl.com/c4ypfg
Another reason for Medabiliti to distance itself from Groklaw was XM Network,
written on open source software and never shared back to the community. See
http://tinyurl.com/dgssaa
In regard to Solaris 8 source code in Linux, there'll be plenty of time in
the near future to prove the speculation.
Re: IBM's future is indeed tied to Sun's acquisition anonymous-insider on
04/07/2009 at 6:00 PM
"And They Call Linus Careless"
http://www.groklaw.net/articlebasic.php?story=66
"SCO's Amended Complaint attacks Linus for allegedly being careless, allowing
code in without checking for IP problems first."
On November 2, 2001, Alan Cox announced "Marcelo Tosatti will be the head
maintainer over the 2.4 stable kernel tree", see http://www.advogato.org/article/370.html
and http://tinyurl.com/cbtlez .
Did Marcelo Tosatti had the age and the experience to discern if code added
to the Linux kernel was free of copyright infringement? For an answer, see http://web.archive.org/web/*/http://marcelothewonderpenguin.com
A few weeks after Tosatti was named the new Linux 2.4 kernel maintainer,
an e-mail message was transmitted over the Internet. The subject of the message
was "2.4.16 & OOM killer screw up".
A well-known Linux kernel developer wrote "The VM code lacks comments, and
nobody except yourself understands what it is supposed to be doing."
Another Linux kernel developer wrote "Andrea, it seems -aa is not the holy
grail VM-wise. If you want to merge your good stuff with marcelo, please do
it in the 'one patch with explanation per problem' style marcelo asked."
The 'author' of the VM code responded "it's not true that I'm the only one
who understands it. For instance Linus understand it completly, I am 100% sure."
All the "2.4.16 & OOM killer screw up" messages have been gathered in one
single URL, see http://tinyurl.com/dxse7b . Nevertheless, copies of the entire
electronic exchange are available in the Web in different locations.
Allowing a young and inexperienced Brazilian programmer to maintain Linux
kernel version 2.4.16 and later 2.4 releases was indeed a careless decision
by Linus Torvalds. Or was the decision intentional?
Robert X Cringely's quote, not mine
anonymous-insider on 04/20/2009 at 7:40 PM
It was Robert X Cringely who wrote
"While IBM has the upper hand in the SCO
suit, which has been ongoing since 2003, it has become clear that some code
commingling has taken place, which could hurt future copyright and intellectual-property
claims over software developed for Linux and AIX."
Now that Oracle has formally made a deal with Sun, it's definitely IBM's
loss. Very similar to Cringely's narration on how Gary Kildall sent IBM away.
In this case, it was IBM's turn to send Sun away.
This is the same Jeremy Allison which resigned from Novell and jumped to greener
pastures of Google under the pretext of protest over the
Microsoft-Novell
patent agreement, No he is biting the hand that feeds him: Google... May
be he had found another company to move to...
But now consider the strange new world of cloud computing, and software as
a service. The way software works in this world is completely different. Most
of the complex logic and the actual programs themselves live as software only
running within server farms, communicating solely by network requests sent from
a client Web browser via downloaded Javascript programs.
There is no “distribution” here, so the reciprocal clause of the GPL is never
triggered. In such a world, service providers can use GPL-licensed code in proprietary
back-end server farms with impunity. This seems contrary to the spirit of the
authors of much of the GPL-licensed code used in this way, although it strictly
complies with the license. It means that, as Bradley warned, GPL code can be
used in the cloud computing market in exactly the same way as BSD code can be
used in the traditional software market.
Dec 20, 2008 |
Yaakov Nemoy
Summary, in case you want to skip this.
Open Source development is pretty close to Anarchism. Still, we rely on the
courts and government to protect Open Source. What if we were to lose that support,
what would the Open Source ecosystem look like then?
Before i begin, let me redefine Anarchism away from the bad taste in your mouth,
purely chaotic society where anyone will kill his parents if it means a few
bucks. It's really an insult to the decency of mankind to presume anyone would
act in such a way. When i refer to anarchism, i refer to a self regulating,
self ruling society where the individual decides which rules are important.
I was watching an interview with Eric S. Raymond where the interviewer asked
him the million dollar question: "Is Open Source Communism?". His response was
extreme disgust, and his argument against this was about the very nature of
Communism. Communism forces the individual to share and participate in a single
monoculture society, where if you chose not to be a member, you were thrown
in the Gulag, shot in the back of the head, and even buried in an unmarked grave.
The question was raised around the 'viral' aspect around the GPL, in how it
forces the redistributor to retain that license on all modified code. But let's
face it, very few people actually want to force people to use the GPL and nothing
but the GPL.
Let's take this completely the other direction. Economically, Capitalism is
considered the economic polar opposite* of Communism. The idea behind Red Hat
is that Open Source makes perfect business sense, because it's been proven to
encourage faster economic development than the traditional methods that preceded
Open Source development. Capitalism is certainly akin to Anarchism, in that
they both encourage a certain free growth, unimpeded by any other limitations.
For example, in our society, most capitalistic economies are limited by government
regulation, but are otherwise completely subject to the consumer demand.** Capitalism,
especially as Open Source moves into it more, relies on a set of organically
grown collective agreements between the different corporations. Still, it relies
on a level of government regulation and intervention to support and maintain
these agreements. For example, corporations rely more than ever on the court
systems to enforce trademarks worldwide, because without an overarching court,
any individual can use a trademark freely with little retribution. Open Source
moves corporations into a space though, where they no longer compete with each
other directly, but actually support each other. This is fairly close to an
anarchistic economy.
written by
Armin Ronacher, on Thursday,
February 12, 2009 7:13.
When I started using Linux I was totally sold to the concept of Open Source.
I still am, but my view changed. The first code I released under an Open Source
license was GPL licensed and I continued to do so for some time.
The last code under the GPL license I actively developed was
Zine until a few days before the release
when I relicensed it under the modified BSD license.
The reason why I changed the license is a rather complex one and I want to
share my experiences with the GPL and other Open Source licenses
here for a moment. I suppose many people acted like me and chose the GPL
because everyone else did but didn't know about all the implications it has.
Left versus Right
The GPL and BSD (and friends) licenses couldn't
be more different. It starts with the length of the paper. The BSD
license is two or three clauses of text plus a copyright information and no-warranty
clause. The GPLv3 on the other hand has 600 lines of text.
BSD restricts the rights, GPL permits. Restricting
rights sounds bad, but it just means that you can do everything with it, except
the stuff listed in the license. The GPL starts by explaining what
you can do with it. The GPL is following the
Copyleft principle, something
the BSD license is not doing.
This has some very complex implications many GPL / BSD
users don't know about but should.
What BSD means
Let's start with the BSD license, the license of my choice.
The three clause version is very similar to the MIT license and
the two clause version is basically the MIT license. What does
it say?
Copyright (c) <year>, <copyright holder>
All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
- Neither the name of the <organization> nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
Pretty simple. It allows the user to do everything with the application but
removing the Copyright. The third clause means that derived works may not use
the author's names for advertising. This clause is not in the 2 clause
BSD and MIT licenses.
Now this of course means that someone can take your software, change the
branding and sell it. The world is bad and you can be sure that this will happen
if your application is worth it. We'll cover that part of the license a little
bit later.
Let's see how the GPL works there.
What GPL means
The GPL license is too long to be quoted here, but I'll try
to sum up the most important aspects of it:
- Copies may be distributed free of charge or for money, but the source
code has to be shipped or provided free of charge (or at cost price) on
demand. The receiver of the source code has the same rights meaning he can
share copies free of charge or resell.
- The licensed material may be analysed or modified.
- Modified material may be distributed under the same licensing terms
but don't have to be distributed.
There is a lot more in the license, like how long source code has to be available
and how to deal with that, but the essence is that. Like for the BSD
license someone can take the application, rebrand it and sell it, however the
license demands that the modified source is available under the same license.
However modifications only have to be made available to the public if distribution
happens. So it's perfectly fine to take GPL code, modify it heavily
and use it in a not distributed application / library. This is how companies
like Google can run their own patched versions of Linux for example.
But what this also means is that non GPL code can't use
GPL code which is also the main problem of it.
License Compatibilities
BSD is GPL compatible, but GPL does
not permit the use of GPL licensed code in non-GPL
code. This is especially annoying if important libraries users expect are
GPL. For example the very popular
readline library is
GPL licensed. Users of OS X will know that, because interactive
shells of Python and other non GPL applications sucks there. People
tried to rewrite readline to get rid of the GPL problem but the
alternatives are not as well maintained as the original one.
I guess this is also what Steve Ballmer referred to as “cancer”. Unfortunately
he's not entirely wrong there. For example I tried to develop an interactive
administration shell for Zine but without
readline (which I cannot use as Zine is BSD licensed) the user
experience is just meh. I would have to relicense the entire application to
GPL just so that I can have an interactive shell with
readline support.
Freedom
Now this depends on how you define freedom. The people behind the GPL
have a very communistic point of view in terms of freedom: free software should
be available to everybody under the same terms. Unfortunately like communism
it does not work out that well because it turns out humans are not really compatible
to that way to look at things. On the other hand there are the permissive licenses
like BSD that just give away all rights except the copyright and
do not enforce freedom. You can take BSD code and re-license it
under the GPL if you want to. That kind of freedom however is a
one-way ticket. Once you made a GPL release of your code there
will always be a GPL version of it. If not for future releases,
at least for that one release as you can't revoke the license.
Making Money
Ultimately the goal of software development for many is to make money. Many
people decide to utilize the GPL license for that by dual-licensing
the code under the GPL and a proprietary license where the latter
is only available to costumers. As a single developer it's arguable harder to
sell code that is licensed under the BSD license. There the business
model is probably more selling non-open-source extensions to paying costumers.
If you open source all your code under the BSD you have to be really
good so that you can make money out of it.
Many developers don't really care about that, have their fun developing it
and BSD license it for others to start where they stopped. A good
example of successful BSD / MIT code are
Django and
Ruby on Rails. Both projects developed
by strong communities with supporting companies behind it. The company behind
Rails creates very successful closed source applications based on Rails; Many
of the developers working on Django are paid by individual companies that work
with it.
Recap
Before you license your code under an Open Source license: Think about the
license! Both types of licenses have their advantages and disadvantages and
it would be stupid to use the GPL without thinking just because
“everybody does”. Many just do because they haven't read the license either.
August 15, 2008 | legaltimes.typepad.comFederal Circuit: Copyright
Infringement Applies to 'Artistic' Licenses
Free software is available everywhere on the Web, and downloading it is a
cinch. But breaking the terms of so-called “open-source" or artistic licenses
can amount to copyright infringement, the U.S. Court of Appeals for the Federal
Circuit in the District of Columbia
ruled this week.
The appeals court in a California case reversed
a federal district court ruling that said a person who breaks the terms of an
artistic license can be held liable for breach of contract, not copyright infringement.
The remedy for infringement — including injunctions, statutory damages and attorney’s
fees — can be more substantial than a breach of contract award.
Bob Jacobsen, a physics professor at the University of Berkeley, manages
a software group called Java Model Railroad Interface, which controls a programming
application called DecoderPro. Model railroad enthusiasts use DecoderPro to
program chips in model trains. Jacobsen accused Oregon resident Matthew Katzer
and Kamind Associates of copying materials from the publicly available software
and incorporating it without following the terms of the public license. Jacobsen
filed a copyright infringement complaint and sought an injunction against Katzer
and Kamind Associates of Hillsboro, Oregon.
The U.S. District Court for the Northern District of California, in San Francisco,
ruled Jacobsen’s artistic license was “intentionally broad” and had unlimited
scope. The Federal Circuit remanded to the district court, where Jacobsen’s
complaint was filed in 2006. A status conference will be held in the coming
weeks.
“This decision confirms what everyone in the community knew, that the terms
must be followed or it is copyright infringement,” Jacobsen’s attorney, Victoria
Hall of Bethesda, told Legal Times. A message left with Katzer’s attorney,
R. Scott Jerger of Field Jerger, in Portland, Oregon, was not immediately returned.
Katzer could ask for a rehearing en banc or petition the Supreme Court for certiorari.
Much of the open-source litigation, Hall said, has been disposed through
arrangements between the parties and through settlements. Bloggers advocating
open-source software heralded the Federal Circuit’s ruling. Appeals of copyright
law are rare in the Federal Circuit compared to patent law litigation.
“Copyright holders who engage in open source licensing have the right
to control the modification and distribution of copyrighted material,"
the Federal Circuit said. Chief Circuit Judge Paul Michel of the Federal Circuit,
Circuit Judge Sharon Prost and U.S. District Judge Faith Hochberg of the Northern
District of New Jersey issued the order.
The judges said: “Open source licensing has become
a widely used method of creative collaboration that serves to advance the arts
and sciences in a manner and at a pace that few could have imagined just a few
decades ago."
| From: |
|
Linus Torvalds <torvalds-AT-linux-foundation.org> |
| To: |
|
Alexandre Oliva <aoliva-AT-redhat.com> |
| Subject: |
|
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL
V3 |
| Date: |
|
Tue, 12 Jun 2007 08:45:46 -0700 (PDT) |
| Cc: |
|
Ingo Molnar <mingo-AT-elte.hu>, Tarkan Erimer <tarkan-AT-netone.net.tr>,
debian developer <debiandev-AT-gmail.com>, "david-AT-lang.hm" <david-AT-lang.hm>,
Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>, Andrew
Morton <akpm-AT-linux-foundation.org>, Greg KH <greg-AT-kroah.com> |
| Archive-link: |
|
Article,
Thread
|
On Tue, 12 Jun 2007, Alexandre Oliva wrote:
>
> Per this reasoning, Sun wouldn't be waiting for GPLv3, and it would
> have already released the OpenSolaris kernel under GPLv2, would it
> not? ;-)
Umm. You are making the fundamental mistake of thinking that Sun is in
this to actually further some open-source agenda.
Here's a cynical prediction (but backed up by past behaviour of Sun):
- first off: they may be talking a lot more than they are or ever will
be doing. How many announcements about Sun and Linux have you seen over
the years? And how much of that has actually happened?
- They may like open source, but Linux _has_ hurt them in the
marketplace. A lot.
They almost used to own the chip design market, and it took quite a
long time before the big EDA vendors ported to Linux (and x86-64 in
particular). But when they did, their chip design market just basically
disappeared: sparc performance is so horribly bad (especially on a
workstation kind of setup), that to do chip design on them is just
idiotic. Which is not to say that there aren't holdouts, but let's face
it, for a lot of things, Solaris is simply the wrong choice these days.
Ergo: they sure as hell don't want to help Linux. Which is fine.
Competition is good.
- So they want to use Linux resources (_especially_ drivers), but they do
*not* want to give anything back (especially ZFS, which seems to be one
of their very very few bright spots).
- Ergo: they'll not be releasing ZFS and the other things that people are
drooling about in a way that lets Linux use them on an equal footing. I
can pretty much guarantee that. They don't like competition on that
level. They'd *much* rather take our drivers and _not_ give anythign
back, or give back the stuff that doesn't matter (like core Solaris:
who are you kidding - Linux code is _better_).
End result:
- they'll talk about it. They not only drool after our drivers, they
drool after all the _people_ who write drivers. They'd love to get
kernel developers from Linux, they see that we have a huge amount of
really talented people. So they want to talk things up, and the more
"open source" they can position themselves, the better.
- They may release the uninteresting parts under some fine license. See
the OpenSolaris stuff - instead of being blinded by the code they _did_
release under an open source license, ask youryourself why the open source parts are not ready
to bootstrap a competitive system, or why they are released under
licenses that Sun can make sure they control.
So the _last_ thing they want to do is to release the interesting stuff
under GPLv2 (quite frankly, I think the only really interesting thing they
have is ZFS, and even there, I suspect we'd be better off talking to
NetApp, and seeing if they are interested in releasing WAFL for Linux).
Yes, they finally released Java under GPLv2, and they should be commended
for that. But you should also ask yourself why, and why it took so long.
Maybe it had something to do with the fact that other Java implementations
started being more and more relevant?
Am I cynical? Yes. Do I expect people to act in their own interests? Hell
yes! That's how things are _supposed_ to happen. I'm not at all berating
Sun, what I'm trying to do here is to wake people up who seem to be living
in some dream-world where Sun wants to help people.
So to Sun, a GPLv3-only release would actually let them look good, and
still keep Linux from taking their interesting parts, and would allow them
to take at least parts of Linux without giving anything back (ahh, the
joys of license fragmentation).
Of course, they know that. And yes, maybe ZFS is worthwhile enough that
I'm willing to go to the effort of trying to relicense the kernel. But
quite frankly, I can almost guarantee that Sun won't release ZFS under the
GPLv3 even if they release other parts. Because if they did, they'd lose
the patent protection.
And yes, I'm cynical, and yes, I hope I'm wrong. And if I'm wrong, I'll
very happily retract anything cynical I said about Sun. They _have_ done
great things, and maybe I'm just too pessimistic about all the history
I've seen of Sun with open source.
The _good_ news is that Jonathan Schwartz actually does seem to have made
a difference, and I hope to God he is really as serious about
open-sourcing things as he says he is. And don't get me wrong: I think a
truly open-source GPLv3 Solaris would be a really really _good_ thing,
even if it does end up being a one-way street as far as code is concerned!
Linus
(Log
in to post comments)
Yes, I am an EDA developer, who once developed primarily on Solaris/Sparc
and who now develops primarily on Linux. Sun dropped the ball years ago; they
had a Solaris/x86 in the early 90s that never got any attention, because Sun
management wanted to put "all the wood behind SPARC".
Provided that Sun eventually does go the GPLv3 route, or if other GPLv3 code
appears interesting, Linux could start a transition to a dual license: GPLv2
or GPLv3. The advantage of those terms is that they would achieve the advantages
of GPLv3 (better internationalization, compatibility with other free software
licenses such as Apache's) but still avoid the DRM restriction Linus objects
to (anything GPLv2 permits would still be allowed). Furthermore the kernel already
has a lot of "GPLv2 or any later version" code. A transition would take a while
to do, and a complete transition might require replacement of code from authors
who won't play or can't be located. But the Mozilla project managed to do it;
if Linus asked, I would expect the vast majority of developers to go along.
But it's up to him.
I'm sure Sun is only making these moves to attract developers. But I'm happy
to see more choices.
Furthermore the kernel already has a lot of "GPLv2 or any later version"
code.
I thought the kernel code was licensed under GPLv2 only?
http://lxr.linux.no/source/COPYING
Also note that the only valid version of the GPL as far as the kernel is
concerned is _this_ particular version of the license (ie v2, not v2.2 or
v3.x or whatever), unless explicitly otherwise stated.
The kernel as a complete work is GPL V2 only. Many of the individual files in
the source though have the V2 or later language in them. So, if a relicensing
project were started to bring the complete work of the kernel to GPL V3, those
files would already be taken care of.
How would a dual-licensed Linux help, though? If you go that route, you still
can't port things like ZFS, since that'd be - if it's GPL'ed at all - GPLv3
only. So the only way to port it would be to essentially split Linux into a
GPLv2 version and a GPLv3 version; and given that there'd likely be code (old
or new) that would be GPLv2 only, the latter would not even be a superset of
the former.So as long as Linu(x|s) doesn't go GPLv3, period, there would
really be no way to make code flow from Solaris to Linux, and in fact, a dual-licensed
version of Linux with an "official", integrated GPLv3 branch would actually
make it easier for Sun to pull in code from Linux.
But then, maybe Linus is just a strategic genius, too - maybe all his vocal
opposition to the GPLv3 is just a clever ploy to lull Sun into a false sense
of security, and once they've released Solaris and/or ZFS under the GPLv3, he'll
just switch over as well[1] and reach the rewards. ;)
1. Yeah, I know, he can't just do that, but for the sake of the joke, let's
pretend he can.
The v2 and v3 GPL variants are explicitly compatible with each other in both
directions. So there's no reason the kernel couldn't simply ship different parts
of the tree under different licenses. No fork would be required except in the
case where someone wanted to put together a "GPL2 only" distribution for some
reason.
GPLv2 and GPLv3 are not compatible in either directionthe only thing that
lets GPLv2 code change to GPLv3 is if people gave the FSF a blank check and
said 'GPLv2 or later'
True:
When we say that GPLv2 and GPLv3 are incompatible, it means there is no
legal way to combine code under GPLv2 with code under GPLv3 in a single
program. This is because both GPLv2 and GPLv3 are copyleft licenses: each
of them says, “If you include code under this license in a larger program,
the larger program must be under this license too.” There is no way to make
them compatible.
The FSF took great efforts that GPL versions can be made compatible. The
paragraph that deals with it is section 9 of the GPL. Read it, especially the
last part - many files in the Linux kernel are not explicitly restricted to
a specific GPL versions, which means "any version". And section 6 makes sure
that everybody receives a license from the original licensor, not from a compilation
editor like Linus Torvalds.
The compilation editor (Linus Torvalds) can set terms under which he redistributes
the work, i.e. conditions he has to follow. But since everybody receives the
license from the original licensors, this "restriction" is null and void, you
still can make a compilation yourself which does not restrict the license version,
and then, most parts of Linux are compatible with GPLv3 (because you can either
choose any GPL or explicitely v2 or later).
That kind of compatibility is not much help, unless all of the kernel is licensed
as "v2 or later". As long as there is a single file licensed under "v2 only",
it becomes impossible to link with a single "v3 only" file.
Meanwhile, relicensing all files under a "v2 or later" license might seem
to be a necessary first step to a GPLv3 kernel. But given Linus' reluctance
to blanket license, I would rather expect a "dual v2-v3" license, if the migration
is to be done at all.
Maaaybe there was a good reason why the FSF recommended the use of "v2 or later"
licensing. Then you basically leave the choice to the user. I never understood
what Linus didn't like about that, except some unspecified fear of the FSF,
which would be not only ridicolous but also unfortunate.
It is not so unreasonable: Linus
said:
How can you _ever_ sign anything sight unseen? That's just stupid, and that's
totally regardless of any worries about the FSF.
Said that way, it looks like the correct thing to do. However, given that (as
you say) "v2 or later" licensing gives the choice to the user, I'm not particularly
worried about misuse.
It creates the possibility that code created in a downstream work may not be
usable upstream. Linus has put his cards on the table in the past; he wants
code back.
Instead of "ridiculous and unfortunate" I would say "justified by current events."
We could also theorize that Linus is hinting at the possibility of switching
Linux to GPLv3 to dissuade Sun from releasing ZFS under GPLv3.
But why would not Linus want ZFS in the kernel? The history of Linux shows
that reimplemented code is more successful that ported code. XFS and JFS are
rarely used, whereas ext2 and ext3 are wildly popular.
Patent issues. If Sun releases ZFS under GPLv3, ZFS is patented, and its patents
on ZFS are valid, then anyone else using GPLv3 can use ZFS. They can even "bring
in" the GPLv3 code and completely rewrite it, so the IMPLEMENTATION may be different
but they'd still be okay legally (I think). Using GPLv2 wouldn't give them access
to patents released only under GPLv3.
One would expect Sun already considered this aspect already assuming Sun will
release OpenSolaris under the GPL v3.
> JFS [is] rarely used--Depends on who you
ask. I use JFS now almost exclusively for Vmware and "bkps" (read: large) filesystems,
where before I would use ReiserfsV3 with notail.
--After seeing how fast (and reliable) JFS is, I switched almost all my Reiser
filesystems over to it - and have been much happier. Reiser is great for root
and squid (tail-packing) but not ideal when you're trying to run a VM from a
USB2 IDE drive. JFS makes it usable.
If all of the kernel code were GPLv2 || GPLv3, it could be combined with a GPLv3
ZFS. The collection as a whole would be GPLv3 only if ZFS were added, but ZFS
could be a module, and everything would be legal, while embedded software developers
who want to do DRM could still use the rest of Linux (except ZFS).
Linus is right, Sun don't want Linux source code, they want Linux' kernel hackers
(and then later Linux' users).
Of course CDDL is hopeless is this regard as hackers must transfer copyright
to Sun, who want to do that?
Sun have to fix the bootstrap problem too: it's now not possible to build
a complete free Solaris "distribution". You must use some non free Sun tools
at some point.
Who wants to contribute to project you can't build yourself?
To be fair, Sun's launching a project, called "Indiana", to correct that deficiency
and produce something that would resemble a GNU/Linux distribution. It will
take them some time to do it, but I'm looking forward to it.
Of course CDDL is hopeless is this regard as hackers must transfer copyright
to Sun, who want to do that?
This is false.
You need to sign a
contributors
agreement with Sun, granting Sun joint ownership, if you wish to
have Sun incorporate any contribution to various open-source projects which
Sun founded and maintain (such as OpenSolaris, amongst other projects).
However the CDDL does not require any copyright transfership, and
you're quite free to take and hack away on CDDLed code, like OpenSolaris, without
giving copyright ownership to Sun or anyone else.
such as myself, what is ZFS and what makes it so hot?
http://www.opensolaris.org/os/community/zfs/
Because it's a nice product of computer engineering. Here's a quote from a
nice-to-read
geeky background article :
64 bits would have been plenty ... but then you can't talk out of your ass
about boiling oceans then, can you?
Simon
I have to assume Linus knows that. Sigh. If not, like another poster here, he
should Google... I'm tired of posting ZFS linkfests ;-)He's treading close
to the FUD-line with this one. There's also a hidden assumption here that Jonathan
Schwartz is being disingenuous with his massively revamped corporate strategy.
Sun's a hardware company. They're happy for you to run Linux on your Sun
gear if you prefer - it's a supported option - heck, they even support Windows.
I don't think it's anywhere near FUD, personally. It sounded simply like classic
Linus--he's being very transparently honest. He hopes and wishes that Schwartz
and company are being as open and forthright as they claim to be, but knowing
human nature and the temptations that beset us, he is keeping his powder dry
and his head down, so to speak.
It's not very "forthright" to inject snide Linusisms such as "the only
really interesting thing they have is ZFS, and even there, I suspect we'd be
better off talking to NetApp"! XFS is already integrated, and that has about
as much in common with ZFS as WAFL does.
It comes across as sour grapes about the license,
and even some N-I-H ("core Solaris: who are you kidding - Linux code is _better_").
Btw, there is as much spurious rancor of the opposite polarity from the Sun
camp, as recent zfs-discuss flamefests can attest.
Why can't we all just get along? - Admit that some people like BSD license,
some people like GPL, Sun likes CDDL for now, and ZFS plain rocks... :)
Linux devs ignore it at their peril; Linus, being an engineer of Sun's calibre,
could do a much more helpful job of deconstructing the issue.
The issue with Sun is not that they prefer a particular license, but that they
are choosing to license patents only to code that uses their particular license,
while IBM, Red Hat, Novell, and others are licensing a number of patents (or
in Red Hat's case, all their patents) to developers who use a much larger set
of open source licenses.
This still does not fully explain to me why, to date, kernel devs aren't looking
dispassionately as the affordances of ZFS and how they might have them without
stepping on anyone's patent*. Max V. Yudin recently asked on zfs-discuss,
... is it legal to write ZFS clone from scratch while maintaining binary
compatibility with original?
Jeff mentioned in his blog that Sun filled 56 patents on ZFS related
technologies. Can anybody from the company provide me with more information
about this?
If porting ZFS to Linux kernel is not an option and I were to implement
different file system with ZFS ideas in mind how can I be safe and not break
any Sun patents?
There has been no meaningful resolution of his questions. At least it may
prove that, thanks to software patents, interesting development is now impossible.
So much for stimulating innovation...
* - I suppose NetApp has patents too, but perhaps Linus wishes to imply that
they would be more tractable to deal with than Sun (maybe he actually knows
somebody @ NetApp). Let's dream for a moment, and imagine that Linus and Jonathan,
over a piña colada one Sunday, work out a magical way to free ZFS for
kernel inclusion. That would be a P/R coup for Sun an order of magnitude greater
than even the Apple buzz. Since Solaris 10 famously runs on all varieties of
hardware (IBM, HP, Dell, even Macs), I don't seriously think Jonathan believes
this would damage hardware sales. Then again, I only have the ponytail, not
an MBA, and my bonuses are a few zeroes short of his. ;-)
One could always start from
Sun's GPLv2 ZFS code in GRUB. And Jonathon Schwartz has just posted saying
Linux ZFS would have full patent indemnity.
That said "GPL v2 or later" if I read correctly. I didn't take the time to read
the code, but presumably that is only code for reading and would not affect
potential patents on writing parts.On another note, if Sun make Solaris GPL3
and accept external contributions, it might get tricky to keep parts (i.e. ZFS)
under another licence.
note that the zfs code released for grub is not enough to actually be able to
write to the filesystem, just enough for grub to be able to find the files that
it needs.
I suppose NetApp has patents too, but perhaps Linus wishes to imply that
they would be more tractable to deal with than Sun
Yes, Netapp
has patents, and they caused Daniel Phillips to
stop
working on the tux2 filesystem; I have not followed the story enough to
know if Netapp did anything other than file the patents to achieve this result.
Netapp's WAFL is not very interesting for Linux anyway, because it requires
special NVRAM hardware to buffer writes during some of the more time-consuming
operations (e.g., snapshot creation). I don't think that this hardware dependence
can be eliminated without major changes to the WAFL code.
Concerning not breaking Sun patents, you can look for older sources where
similar ideas have been described, e.g., various papers on log-structured file
systems, e.g.,
our Freenix
2000 paper, or (maybe too young)
my file system ideas.
> XFS is already integrated, and that has about as
much in common with ZFS as WAFL does.That is plain wrong. XFS is in
the huge class of traditional filesystems with a static mapping between file
offsets and device offsets. ZFS is in the somewhat smaller (ignoring reseach
projects) class of COW filesystems, just like WAFL.
Anyone unable to see the similarities is well advised to read more and
write less. ;)
As you see I haven't studied XFS in depth, but I was under the impression it
was COW like ZFS. AFAIK, WAFL also lacks the more interesting features of ZFS
(foremost being end-to-end checksumming).
Checksums are easy to add once you have a COW format. Either you add them to
the block pointers, as ZFS did, or you add them to the objects themselves, as
JFFS2 and LogFS did.
Either way you have an incompatible format change. But the amount of code
affected if rather small. Took about 1-2% of the effort to design a new filesystem
in the LogFS case.
Maybe so, but there's quite a lot of catch-up to do. Once you have COW, transactions,
and checksums, then you want self-healing; then snapshots; pools; quotas; compression;
and so on, until you eventually have something like ZFS. :)
Linus' grandstanding aside, it's possible there is quiet work going on to
improve the situation, as David Magda commented on zfs-discuss:
Somewhat off topic, but it seems that someone released a COW file system for Linux (currently in 'alpha'):
* Extent based file storage (2^64 max file size)
* Space efficient packing of small files
* Space efficient indexed directories
* Dynamic inode allocation
* Writable snapshots
* Subvolumes (separate internal filesystem roots)
- Object level mirroring and striping
* Checksums on data and metadata (multiple algorithms available)
- Strong integration with device mapper for multiple device support
- Online filesystem check
* Very fast offline filesystem check
- Efficient incremental backup and FS mirroring
http://lkml.org/lkml/2007/6/12/242
http://oss.oracle.com/~mason/btrfs/
Via Storage Mojo
> Maybe so, but there's quite a lot of catch-up to
do. Once you have COW, transactions, and checksums, then you want self-healing;
then snapshots; pools; quotas; compression; and so on, until you eventually
have something like ZFS. :)
Sure, ZFS has an impressive set of features. If nothing else, it has showed
how things can be done. And I have little doubt that btrfs, which you quoted,
will end up having most of those features relatively soon. And even if Chris
dies tomorrow, I'll keep working on LogFS.
The only question is when, not if. :)
The only question is when, not if. :)
From comments I've heard, and the buzz around Linus' and Jon's posts, there
seems to be considerable community interest around ZFS (I don't want to use
anything else, or wait, so I switched to Solaris 10 some time ago).
Look forward to more news on this front. Did you follow-up on LKML? (I have
not checked :)
> From comments I've heard, and the buzz around Linus'
and Jon's posts, there seems to be considerable community interest around ZFS
(I don't want to use anything else, or wait, so I switched to Solaris 10 some
time ago).> Look forward to more news on
this front. Did you follow-up on LKML? (I have not checked :)
My personal interest is in flash, not hard disks. Therefore ZFS is impressive
technology, but solving someone else's problem. It is not the last word in filesystems
either, as the fsck will run for hours or days if it ever becomes necessary.
So there remain valid reasons to work on different filesystems.
Impressive technology none the less.
It has been said that COW is ideal for Flash. Can you explain why ZFS isn't
relevant here?
There is no fsck; ZFS is "always consistent on disk" (through COW+atomic
transactions). It seems to me this is a necessary invariant to achieve its other
features (such as snapshots). Debate flares up (occasionally) as to whether
a scavenger will be necessary. If so, it won't much resemble 'fsck' - and certainly
won't be run in normal operation or after reset/powerfail/etc (ZFS behaviour
under impromptu reset is
extremely
well tested).
I suspect, but correct me if I'm wrong, once you "know" you've lost data
in ZFS (through exhausting redundancy or ditto blocks), it's actually gone by
definition, and unrecoverable by re-creating links. No doubt Bonwick et all
have explained it better somewhere...
> It has been said that COW is ideal for Flash. Can
you explain why ZFS isn't relevant here?Raw flash behaves sufficiently
different to hard disks that some ZFS design assumptions become untrue. Flash
has large erase blocks. Within erase blocks, data must be written from front
to back. Writing the block again requires erasing all of it. So the filesystem
block size either has to be equal to the erase block size, or you need garbage
collection. And with garbage collection comes a nasty deadlock problem most
people don't even realize exists. :)
Next comes wear out and protection against it. Afaics, ZFS has several hot
zones that receive significantly more writes than others.
I guess those two are the big reasons.
i dont think i can agree with it. that was a blog last time about the linux
kernel having problem scaling beyond 8-way compared to bsd. not sure whether
they have solved it. on the other hand, linux has
definitely revived interest in unix.
You are seriously out of date; folks at SGI have Linux running on
1024 processors.
The Solaris and BSD folks cannot claim to be more scalable than Linux at
this point; it appears that the reverse is true.
> linux kernel having problem scaling beyond 8-way
compared to bsd.
You're several years behind. A long time_t in LKML-land.
Poster is probably talking about this blog entry
http://jeffr-tech.livejournal.com/5705.html
So he is right, and Linux did have a problem on this workload. Basically
it was a combination of a glibc inefficiency and the fact that nobody seems
to have reported such a workload before. The fix was basically
a small change to the way malloc/free works, and a little patch to the kernel
to optimise the new path used by glibc.
http://www.thisishull.net/showpost.php?s=5d2bfa8b5a070728...
That post found the fixes to have eliminated the big dropoff. Note it still
doesn't scale past 8-way, but this is likely to be a MySQL issue -- BSD doesn't
do any better.
Those things seem to have triggered some sort of bug.Rest assured people
do have real-world Linux boxes that have over 512 cpus in a single system image.
SGI has boxes, at least, have Linux boxes with 4096 cpus in a single system
image.
As far as clustering goes.. there are Linux systems with tens of thousands
of cpus going.
Linux kernel itself does scale past 8 cpus. Of course nothing is perfect.
You could read Jonathan Schwartz's reply to this post. I think he clarifies
a lot of issues as to what Sun is looking at.
This post is actually worth a good read.
Reads like typical salesmanship. Sales talk always "sounds" good...I actually
disagreed with his implication that communities don't compete (only corporations).
There exists competition in the OSS community.
There difference may be that it's augmentative competition rather than destructive
- In business, it's optimal to completely eliminate rivals. In open source,
you don't have to do that; you can just do better. It's a more pure meritocracy.
I hope. :)That said, there's still some dirty pool played from time to time,
but since it's played in the open, it hardly festers.
Linus Torvalds, leader of the Linux kernel project and a major figure in
the open-source programming movement, said Wednesday he's "pretty pleased" with
changes in a
third draft of the General Public License (GPL) released Wednesday.
The Linux kernel and many higher-level software packages are governed by
the current GPL 2, and
Torvalds has expressed strong displeasure with earlier version 3 drafts.
After a preliminary analysis of GPL 3, however, some of those concerns are gone
or moderated, he said.
"I'm actually pretty pleased. Not because I think
it's perfect, but simply because I think it's certainly a lot better than I
really expected from the previous drafts," he said in an interview.
"Whether it's actually a better license than the GPLv2, I'm still a bit skeptical,
but at least it's now 'I'm skeptical' rather than 'Hell no!'"
In particular, one provision against digital rights management has been narrowed,
and another that Torvalds feared could lead to multiple incompatible versions
of the GPL has been removed or defanged.
"I'm much happier with many parts of it. I think much of it reads better,
and some of the worst horrors have been removed entirely," Torvalds said.
The Free Software Foundation (FSF) has been accused of working to prevent
co-operation between the free and proprietary software sectors, thanks to new
terms in the latest draft version of the GNU GPL.
Unsurprisingly, the speediest criticism came from Microsoft, whose deal with
Novell prompted the inclusion of the controversial clauses in the first place.
Horacio Gutierrez, Microsoft's vice president of intellectual property and
licensing, told eWeek: "We note that the draft of the GPLv3 does not tear down
the bridge Microsoft and Novell have built for their customers. It is unfortunate,
however, that the FSF is attempting to use the GPLv3 to prevent future collaboration
among industry leaders to benefit customers."
Microsoft holds that Linux infringes several of its patents and late last
year signed a deal with Novell, under which Novell's customers were indemnified
against legal action by Microsoft. Novell was roundly criticised at the time:
the Open Source sector felt that the deal was a tacit admission that Linux does
infringe Redmond's IP, something Novell has strenuously denied.
Many also felt the deal ran counter to the spirit of the GPL, even if it
was technically compliant. Jeremy Allison, now ex-head of Novell's Samba team,
resigned in protest. He said in a memo: "We can pledge patents all we wish,
we can talk to the press and 'community leaders', we can do all the right things
w.r.t. all our other interactions, but we will still be known as GPL violators
and that's the end of it."
Novell maintains that the agreement did comply with the terms of the GPL,
specifically the requirement that all recipients of the code should be treated
equally, since there was no agreement between Novell and Microsoft, just between
Microsoft and Novell's customers.
The new draft specifically prohibits deals like the one done by Microsoft
and Novell from now on.
Morgan Reed, executive director of The Association for Competitive Technology
said the new terms mean the GPL "no longer just defines freedom; it is designed
to punish companies and business models that Richard Stallman just doesn't like".
The FSF's Richard Stallman
believes
the foundation had to do something. He argues that there are four "defining
freedoms" to free software: the freedom to run the program as you see fit, study
and adapt it for your own purposes, redistribute copies to help your neighbour,
and release your improvements to the public.
"The recent patent agreement between Microsoft and Novell aims to undermine
these freedoms. In this draft, we have worked hard to prevent such deals from
making a mockery of free software," he said.
The second draft of GPLv.3 is just that, a draft. There is a 60 day period
during which suggestions can be submitted. You can comment on the draft
here.
Sun Sticks With Solaris CDDL (For Now)
By
Sean Michael Kerner
Whether or not Sun will migrate to the upcoming GPL version 3 license for
OpenSolaris
and Java is a question resulting in much speculation.
Currently OpenSolaris is licensed under Sun's Common Development and Distribution
License (CDDL)
license
and Java is
set to
be licensed under GPL v2. GPL v3 , which is currently still under
development
adds new terms for digital rights management (DRM) and patents that could have
wide ranging effects on licensees.
Sun Microsystems' Chief Open Source Officer, Simon Phipps, explained that
Sun is picking the best license on a case-by-case basis for its software and
will continue to use the license that is most appropriate for the community
involved.
That said, some things aren't going to change.
"I've got no intention of removing CDDL from OpenSolaris as it has been an
ideal license for OpenSolaris," Phipps told internetnews.com. "The CDDL
is doing a fine job with that community. The role of the license is to empower
the innovator and the CDDL is demonstrably doing a good job of empowering OpenSolaris."
Phipps noted that under CDDL, OpenSolaris has grown its user base and contributions.
At least five distributions are now available that are based on OpenSolaris,
which is facilitated by the CDDL.
Just because the CDDL is working doesn't necessarily mean that Phipps won't
consider adding another license to OpenSolaris. He commented that if the community
wants another license than he would consider it. In fact, Phipps noted that
he is just starting to see a debate in the OpenSolaris community on whether
to add GPL v3.
Currently Sun uses the
GPL v2 license
in some of its software applications, though Sun isn't automatically going to
migrate to v3 when it comes out.
Under the terms
of the GPL v2, licensees "have the option of following the terms and conditions
either of that version or of any later version published by the Free Software
Foundation."
However, if "the program does not specify a version number of this license,
you may choose any version ever published by the Free Software Foundation."
Some applications, notably the Linux
kernel
and MySQL
have included the language "GPLv2 only," as opposed to "GPLv2 or later," implying
that an automatic changeover will not occur.
"I look at the 'or any latter version clause' and think it's a really strange
thing for any responsible enterprise to use in its licensing," Phipps said.
"That's carte blanche to a successive body to act in a way that is against your
interests."
The fact that Sun is not using the "or any later version clause" does not
imply any sort of criticism or lack of confidence in the GPL v3 process. Rather,
it's a matter of responsibility, according to Phipps.
Phipps argued that with Java, for example, there are five million developers
that rely on Java for their livelihood. "It would be absolutely irresponsible
of me to license Java in a way that would endanger the livelihood of the developers
working on it," Phipps said.
Sun has been very active in the GPL v3 process since the beginning. Phipps
noted that he has every confidence that GPL v3 will be a license that will be
usable in some areas of Sun's software business.
In the case of both OpenSolaris and Java, the respective communities will
debate on whether or not GPL v3 is right for them, though, in the final analysis,
the decision to actually use GPL v3 is up to Sun.
"Ultimately in each of those cases, Sun is the copyright holder and it is
Sun that has to take the action," Phipps said. "So ultimately the decision is
mine."
"I'm not going to pick a license that is still not published," Phipps said.
"Licenses give freedom to developers and I need to know that the license chosen
gives the developers that I'm serving and protecting the freedoms that they
desire."
Copyright © 1996-2009 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
- The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with.
- We do not warrant the correctness of the information provided or its
fitness for any purpose
- In no way this site is associated with or endorse cybersquatters
using
the term "softpanorama" with other main or country domains (e.g. softpanorama.com) with
bad faith intent to profit from the goodwill belonging to
someone else.
Last updated:
December 14, 2009
The restrictions of the commercial MySQL license are industry standard and talk about what others can do with MySQL code. Contributors under both SCA and CLA grant rights to us, but continue to own their own code and may thus do whatever they please with it -- including releasing and using it under the rules of the GPL. Those are all basic tenets of dual licensing (commercial rules for commercial licensees, GPL rules for GPL licensees) which I believe are widely understood and accepted.
Are there additional utilities and such that are going to be independent enough of the Mysql codebase to allow a dual license?
Over time we at Monty Program Ab will produce a lot of code, tools and extensions for MariaDB and other products that could be dual licensed. I want to keep the options open to dual license these.
It's true that we can't dual license MariaDB as such (as part of it is owned by Sun). This doesn't however stop anyone from buying a license from Sun for the MySQL part and then buy a license from us for the MariaDB part.
The same is true for MySQL/MariaDB storage engine vendors and those companies that provides Dual-licensed extensions to MySQL/MariaDB.
The current MySQL OEM license was updated September 2008, after MySQL was bought by Sun. I don't know how the previous copy of the OEM license looked, but I do know that when I was part of deciding the OEM licensing scheme in MySQL Ab, it was very liberal (as described in my blog). I don't know when things changed (at least I was never consulted or even informed about it), but I know that the current one does not match my principles of how to do dual-licensing of Open Source software.
As you, Kaj, should know, one of my basic principles in doing business is that one should never write or propose an agreement that you would never want to receive or sign yourself. It should be more than clear to you that the current OEM agreement is, for me, not such a document.
As my blog already describes, the current commercial MySQL license does not follow the "industry standard" of dual-licensing (where did you get this idea?); MySQL Ab were much more open in the beginning (and for a longer time than the current limitations have existed) and other dual-licensed project are much more open. It's also clearly not what people expect from an Open Source project as it seriously limits other peoples possibilities to work, use, and do business around the product. I have gotten lots of comments about this, so that part is easily verifiable.
I strongly disagrees with the notion that you can have commercial rules for commercial license, GPL rules for a GPL license. People donate code in to a product because they are using it and intend to recommend and use it in the future. If the commercial license is not agreeable to them, there is no reason for them to donate time and effort to help the project. Why help someone that doesn't understand your needs and is working against you?
Because of that, I strongly recommend anyone doing dual-licensing take their users and contributors into account when defining how they dual-license their software. It's to everyone's benefit to have a liberal dual-licensing policy to create a working developer ecosystem around products that benefit a large number of people.
How do you get bug fixes under this license? Is that covered when you also buy a support contract?
I understand the need to limit the agreement to a particular release as there should be different prices for a customer who only wants a license for 5.0.84 versus someone who wants a perpetual license for all future releases of MySQL. Without such a limit, it is not as easy to define the difference between fixing a bug, using the Percona patch, and upgrading to new versions of official MySQL.
However, I also think that opportunities are being squandered by Sun. If their agreements preclude external developers from having a chance at making money, then I suspect that many of those external developers will stop contributing via the CLA/SCA.
You don't actually know that Sun changed it.
I think it would be best if you retracted the part of the post that slams Sun for changing the license, since you don't know that Sun actually changed it.
Monty said...
Please read my post/comment again; There is no FUD involved, only facts. I did not say that it was Sun who has made the OEM license as restricted as it's now; I just said that, contrary to what Kaj implied, that I was not part in doing such a change.
When it comes to Sun, the only thing that is clear is the OEM license has been changed after Sun bought MySQL (just check the date in the license) and Sun has thus approved of the current content of the license.
The main point is however not if the change was done before or after Sun bought MySQL. The important thing is that the current OEM license for MySQL is something that in my mind is unacceptable when doing Dual-licensing on Open Source software. I think that people contributing code to an Open Source project should be aware of how they code are used and why it's important to know this.
I know that Sun is not the only company that is doing this wrong. However, now when the Oracle / Sun deal gets a lot of attention, it's important to know what Sun is doing so that we can help DOJ to and the EU commission to understand better where MySQL stands now and what they should do to ensure that MySQL stays free in the future. For this to happen, we need to be able to discuss things openly, instead of staying silent. This makes it difficult, since any criticism against Sun can always be called FUD, but anyone in the MySQL community must be allowed to have an opinion and to talk about it in public - that is how Open Source works after all. You can spread more FUD by not saying anything than by being transparent!
A final word about Monty Program. Our business model targets those who use the GPL version of MySQL (or MariaDB). We don't have a self interest in this topic. Sure if things were different, maybe we could do some other business too, but things are what they are. The only reason to bring this up for public discussion was that we were made aware of these problems by people affected by them. After publishing this we have also got feedback from other leaders in the community, that told us they did not know about this and they did indeed assume dual licensing worked differently and were thankful for the blog post.
If you use the standard OEM agreement, you can't use any non default storage engines, you can't fix bugs yourself or ask anyone to fix the bugs for you. You can get a separate support contract from Sun and hope that they fix the bugs you report in the version that you bought the EOM contract for.
I don't think there is a reason to limit an OEM agreement of Open Source software to a particlar versions as if you are all; It's gets too hard to define what changes you can apply or not apply without having to change the version number yourself. I think it's a better business model when you combine Dual-licensing with a separate support offering. This will allow you to get the money from the customer over time when he uses the product for new things instead of trying to get the customer to pay over and over for almost the same code (just because he wants to have the latest bug fixes that is just in the latest release)...