Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend.html

Apple announced last week that its Swift programming language — a
currently fully proprietary software successor to Objective C — will
probably be partially released under an OSI-approved license eventually.
Apple explicitly stated though that such released software will not be
copylefted. (Apple’s pathological hatred of copyleft is reasonably well
documented.) Apple’s announcement remained completely silent on patents,
and we should expect the chosen non-copyleft license
will not contain a patent grant.
(I’ve explained at
great length in the past why software patents are a particularly dangerous
threat to programming language infrastructure.)

Apple’s dogged pursuit for non-copyleft replacements for copylefted
software is far from new. For example, Apple has worked to create
replacements for Samba so they need not ship Samba in OSX. But, their
anti-copyleft witch hunt goes back much further. It began
when Richard
Stallman himself famously led the world’s first GPL enforcement effort
against NeXT, and Objective-C was liberated. For a time, NeXT and
Apple worked upstream with GCC to make Objective-C better for the
community. But, that whole time, Apple was carefully plotting its escape
from the copyleft world. Fortuitously, Apple eventually discovered a
technically brilliant (but sadly non-copylefted) research programming
language and compiler system called LLVM. Since then, Apple has sunk
millions of dollars into making LLVM better. On the surface, that seems
like a win for software freedom, until you look at the bigger picture:
their goal is to end copyleft compilers. Their goal is to pick and choose
when and how programming language software is liberated. Swift is not a
shining example of Apple joining us in software freedom; rather, it’s a
recent example of Apple’s long-term strategy to manipulate open source
— giving our community occasional software freedom on Apple’s own
terms. Apple gives us no bread but says let them eat cake
instead.

Apple’s got PR talent. They understand that merely announcing the
possibility of liberating proprietary software gets press. They know that
few people will follow through and determine how it went. Meanwhile, the
standing story becomes: Wait, didn’t Apple open source Swift
anyway?. Already, that false soundbite’s grip strengthens, even though
the answer remains a resounding No!. However, I suspect that
Apple will probably meet most
of their
public pledges. We’ll likely see pieces of Swift 2.0 thrown over the
wall. But the best stuff will be kept proprietary. That’s already happening
with LLVM, anyway; Apple already ships a no-source-available fork of
LLVM.

Thus, Apple’s announcement incident hasn’t happened in a void. Apple
didn’t just discover open source after years of neutrality on the topic.
Apple’s move is calculated, which
led various
industry pundits like O’Grady and Weinberg to ask hard questions (some of
which are similar to mine). Yet, Apple’s hype is so good, that
it did
convince one trade association leader.

To me, Apple’s not-yet-executed move to liberate some of the Swift 2.0
code seems a tactical stunt to win over developers who currently prefer the
relatively more open nature of the Android/Linux platform. While nearly
all the Android userspace applications are proprietary, and GPL violations on
Android devices abound, at least the copyleft license of Linux itself
provides the opportunity to keep the core operating system of Android
liberated. No matter how much Swift code is released, such will never be
true with Apple.

I’m often pointing out
in my recent
talks how complex and treacherous the Open Source and Free Software
political climate became in the last decade. Here’s a great example: Apple
is a wily opponent, utilizing Open Source (the cooption of Free Software) to
manipulate the press and hoodwink the would-be spokespeople for Linux to
support them. Many of us software freedom advocates have predicted for
years that Free Software unfriendly companies like Apple would liberate
more and more code under non-copyleft licenses in an effort to create
walled gardens of seeming software freedom. I don’t revel in my past
accuracy of such predictions; rather, I feel simply the hefty weight of
Cassandra’s curse.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2015/06/03/lyons-silicon-valley.html

I watched the most recent Silicon Valley episode last night.
I laughed at some parts (not as much as a usual episode) and then there was a
completely unbelievable tech-related plot twist — quite out of
character for that show. I was surprised.

When the credits played, my draw dropped when I saw the episode’s author
was Dan Lyons.
Lyons (whose work has been
promoted by the Linux Foundation) once compared me to
a communist
and a member of organized crime (in, Forbes, a prominent
publication for the wealthy) because of my work enforcing the GPL.

In the years since Lyons’ first anti-software freedom article (yes, there
were more), I’ve watched many who once helped me enforce the GPL change
positions and oppose GPL enforcement (including allies who once received
criticism alongside me). Many such allies went even further —
publicly denouncing my work and regularly undermining GPL enforcement politically.

Attacks by people like Dan Lyons — journalists well connected with
industry trade associations and companies — are one reason so many
people are too afraid to enforce the GPL. I’ve wondered for years why the
technology press has such a pro-corporate agenda, but it eventually became
obvious to me in early 2005 when listening to yet another David Pogue Apple
product review: nearly the entire tech press is bought and paid for by the very companies
on which they report! The cartoonish level of Orwellian fear across our
industry of GPL enforcement is but one example of many for-profit corporate
agendas that people like Lyons have helped promulgate through their
pro-company reporting.

Meanwhile, I had taken Silicon Valley (until this week) as
pretty good satire on the pathetic state of the technology industry today.
Perhaps Alec Berg and Mike Judge just liked Lyons’ script — not even
knowing that he is a small part of the problem they seek to criticize.
Regardless as to why his script was produced, the line between satirist and
the satirized is clearly thinner than I imagined; it seems just as thin as
the line between technology journalist and corporate PR employee.

I still hope that Berg and Judge seek, just as Judge did in Office
Space, to pierce the veil of for-profit corporate manipulation of
employees and users alike. However, for me, the luster of their achievement
fades when I realize at least some of their creative collaborators
participate in the central to the problem they criticize.

Shall we start a letter writing campaign to convince them to donate some
of Silicon Valley‘s proceeds to Free Software charities? Or, at
the very least, to convince Berg to write one of his usually excellent
episodes about how the technology press is completely corrupted by the
companies on which they report?