PowerShell Specification licensed under the Community Promise

http://blogs.msdn.com/b/powershell/archive/2011/04/16/powershell-language-now-licensed-under-the-community-promise.aspx

by brudgers • 15 years ago

65 37 15 years ago

blogs.msdn.com

chrisjsmith2• 15 years ago

The community promise is worthless:

http://www.fsf.org/news/2009-07-mscp-mono

tzs2• 15 years ago

FUD. A summary of their argument is (1) Microsoft has software not covered by the promise, and (2) the promise only covers the patents you need to implement the covered specification. Neither of these makes the promise worthless.

This is no more worthless than the similar promises from IBM, Sun, and many others that cover a huge number of specifications that are widely used in open source. It's the normal way patents are made available for free use in implementing specifications.

lukeschlather• 15 years ago

> The Community Promise does not give you any rights to exercise the patented claims. It only says that Microsoft will not sue you over claims in patents that it owns or controls. If Microsoft sells one of those patents, there's nothing stopping the buyer from suing everyone who uses the software.

Microsoft can sell the patents, and the buyer can sue you. And what happened when Oracle bought Sun? Oracle got sue-happy. It's not like Microsoft has been a model citizen up until now. They're actively suing manufacturers who are using Linux, especially in the consumer space. It's not FUD - it's reality. Microsoft is very clear about what they're planning on doing to manufacturers who dare to ship consumer hardware that doesn't pay the Microsoft tax.

Osiris• 15 years ago

We hope to see implementations on all of your favorite platforms. This would benefit the industry, our partners, and our customers.

It seems they think there is a benefit for themselves to see PowerShell implemented on other platforms.

moondowner• 15 years ago

maybe they should say: "This would benefit Microsoft, our partners, and our customers"

y0ghur7_xxx• 15 years ago

The language specification is only in docx[1].

Microsoft, just put an HTML page with the spec online. There is no need for a docx file for a language specification.

[1]http://www.microsoft.com/downloads/en/details.aspx?FamilyID=...

lloeki• 15 years ago

You're lucky it's not in the Microsoft PDF killer format: XPS!

Still, I always wondered why they keep publishing stuff like this in a "working" format (doc, odt...) instead of a "distribution" format (ps, pdf...) .

keyle• 15 years ago

I've limited knowledge of PowerShell but I can't see why I would want it in my OS? Don't we have enough with bash, ksh etc.?

angdis• 15 years ago

Yep, it has some interesting features/capabilities but the syntax is soooo baroque. All I want out of shell is a means to get boring shit done without having to think about it too much. At this point, Cygwin is STILL the way to go on windows and it would take A LOT of simplification to make powershell even competitive on windows, let alone competitive on *-nix platforms with a plain old shell like bash.

protomyth• 15 years ago

If I could use it on OS X / Linux / OpenBSD to do outlook.com maintenance, I could get rid of the Windows 7 VM.

brudgers• 15 years ago

Discussion of Powershell versus Unix-like approaches from StackOverflow

http://stackoverflow.com/questions/573623/powershell-vs-unix...

andreaja• 15 years ago

There are some very powerful commandlets (basically scripts) for control over various pieces of MicroSoft infrastructure components (Exchange, Active Directory and more). Having access to these commandlets on my favored environment would be useful. I wouldn't even need to be running a PowerShell session to run them, but that would occasionally be nice too (there is something to be said for object pipes).

Niten3• 15 years ago

This isn't pointed at you, keyle, but here PowerShell seems to be one of those things that's universally panned by people who don't understand it, or who refuse to give a serious chance to anything that isn't a traditional Unix shell...

To answer your question, PowerShell's big win is that it's an object-oriented shell on top of .NET. Where the Unix shell pipes flat data, PowerShell pipes .NET (and COM) objects.

In practice this means things that may require complicated and often fragile text-wrangling in the Unix shell are straightforward and robust in PowerShell. For example, suppose you wanted to kill all processes with a private working set greater than 1 GB:

    ps | ?{ $_.PM -gt 1GB } | %{ $_.Kill() }

Here ps returns a collection of all current processes, then pipes it to the where-object cmdlet (abbreviated "?") which filters the collection to those with a private working set greater than the given size. The filtered collection is then piped into the foreach-object cmdlet ("%") which invokes the Kill() method on each object passed in – these are real .NET objects being passed around, so you can invoke methods, set properties, etc.

You can get the same result with a Unix shell script, but you have to be careful to count the columns output by ps correctly, skip the output header, pass it through awk, save the corresponding PIDs and then invoke the kill command on them... and then it all breaks if you run it on a different Unix system where ps outputs a different formatting. In practice you usually leave the shell environment and write a Perl or Python script instead for this sort of thing.

In PowerShell you can directly instantiate .NET and COM objects, and you can implement your own cmdlets and modules either in the PowerShell scripting language or in any .NET language like C# or F#. So e.g. you can access the .NET class libraries to get the time as so:

    [System.DateTime]::Now

And this makes PowerShell handy for interactively developing .NET class libraries (at least until C# gets a real REPL, and if you aren't using F# anyway). Of course this object-oriented approach is all the more necessary on Windows, which is inherently an object-oriented system (think OLE automation, WMI, etc., let alone .NET) than it is on Unix-based systems.

Some people will complain about the PowerShell scripting language... and sure, it's not perfect, but I think the team did about as good a job as possible satisfying the various requirements involved in building a new Windows shell language that could be used both interactively and as the basis for writing scripts. Superficially the language is heavily influenced by Perl, and while I'd still rather use Perl for "serious" automation tasks, PowerShell gets the job done... and it's nowhere near as ugly as scripting in the traditional Unix shell, nevermind the old Windows command shell.

For more on the design rationale, in the words of one of PowerShell's creators:

http://stackoverflow.com/questions/573623/powershell-vs-unix...

angusgr2• 15 years ago

I worked with PowerShell in a past life, and found it quite useful and reasonably pleasant[1] (esp. when coming from standard Windows Shell), however it's this:

In PowerShell you can directly instantiate .NET and COM objects

... that I think will keep it from being especially useful on non-Windows platforms.

Windows has COM objects for pretty much every language/app/platform feature pre-2003, and .NET objects for pretty much everything since. To be equivalently useful, then a ported version would need to find the equivalents on their new platform. That sounds hard to me, especially on platforms like Linux where you have a half-dozen different desktop API possibilities and where the historical focus is on text files, not APIs, for configuration & control.

Without object models to leverage, a PowerShell port will be limited to replicating everything with wrapper objects: starting from Bash functionality, then coreutils, and then slowly working up.

[1] TBH I wish they'd added features to IronPython instead of making a new syntax, but such is life.

jkahn2• 15 years ago

As someone who occasionally has to write PowerShell, I can say with confidence that is an abomination of a language with a horrible syntax. I hope this never gets implemented on any other platform when there are so many superior alternatives.

nahname• 15 years ago

What is it about the syntax that you dislike? I am neither for or against, I just have friends that use it quite frequently and seem fine with it.

norswap• 15 years ago

And bash is so much superior ?

__david__• 15 years ago

Superior alternatives such as...?

code_duck• 15 years ago

I've heard a lot of good things about it, mainly from people used to CMD though. When I checked it out, I didn't find a lot to do with it. I didn't feel like learning a new shell language that only works on Windows. The lack of familiar helper tools such as diff, grep and sed didn't help, and I don't know whatever Windows equivalents may exist. I'm sure if I was using Windows PWSH would be great, but like many of us I don't have any interest in using Windows as a webserver platform.

Now that there may be a prospect of using PowerShell on other platforms, I wonder why I'd bother? Day to day tasks I'm perfectly happy doing in bash, and anything more complex, I'd just as soon use Python, Ruby, PHP or Perl.

seabee• 15 years ago

grep is Select-String

diff is an alias for Compare-Object so if you tried it, you should have seen it do something. But unlike actual diff it operates on objects rather than files, so you need to gc (Get-Content) the files you want to compare.

sed/awk: string manipulation is built-in to PowerShell, but sed's in-place file editing is replicated by piping Get-Content into Set-Content. Sometimes more verbose, sometimes not.

I personally don't see what value PowerShell would bring to other platforms, given they already have huge swathes of scripts written in well-developed (or at least well-discussed) languages and command-line tools for system administration are plentiful. But why would you bother using Perl when you already have Ruby? Obviously some people will take the choice if they know it.

mikemaccana• 15 years ago

Really? Log onto Windows and run:

    ps OUTLOOK.EXE | kill

Note the lack of any regex-munging tools? That's because PS is sending a list of processes, not just lines of text. The constant Unix 'what's a good regex for this or that' problem is gone because content is separate from presentation - which as we all know is good engineering.

I'm a Unix guy. Window Server 2008R2 still requires reboots for trivial activity (eg, installing Office web), which I don't think is appropriate for servers. But PoSH is awesome.

snprbob86• 15 years ago

I too am a Unix guy, but I came from a very Microsoft centric world: Microsoft itself. There, I used PowerShell day in and day out. It's a decent little shell. I much prefer it over cmd! That said, a better description for it would be a REPL. And if you think about it that way, then it's a pretty damn awful shell. It prefers to work with objects, so it tends to be frustrating to work with bytes. Besides, I've already got a great tool for working with objects: Python.

The bottom line is this: If you need a tool for operating on objects, then use a programming language; preferably choose one with a strong REPL. If you need to deal with persistent, serialized, streams of bytes, use a traditional shell.

thwarted• 15 years ago

This means that now anyone can implement PowerShell on any platform they want to. We know some of our most passionate customers sometimes work on platforms that can’t run PowerShell today, so when writing this specification, we wrote it in a platform neutral manner.

We hope to see implementations on all of your favorite platforms. This would benefit the industry, our partners, and our customers. We told you that you should learn PowerShell and we would do everything we could to make it the best investment you ever made. Specifying the language and enabling the community to implement it is yet another step in that direction.

It's interesting how many open source projects are expected to, and do, port their projects to Windows, but Microsoft expects the community to do the work of porting their projects to other platforms. Now obviously, Microsoft isn't usually the one doing the expecting, but Microsoft has a lot more resources than any random person doing a port in their freetime.

I remember when Apache wasn't available for Windows; and I remember when Microsoft "let" the Mono team write their Silverlight port.

This is all just marketing. They can say they are open and working with the community, but they are offering something empty: anyone who wants to use Powershell, or has experienced its value, is already working on Windows and most likely isn't interested in working on any other platform. And thus there is no one (or close to no one) who is both interested in doing and qualified to do a port. And I think Microsoft has shown their track record of working with the community only to continuously leave community products at least one step behind the moving target that is their "standard", often defined as whatever the latest from Microsoft offers. Everyone else's ports are seen a lesser because they are behind the "official" release.

Now, obviously, different implementations are good for the standard and market overall, and only serve to strengthen it from a diversity standpoint. But it's interesting that Microsoft is actively encouraging forks of their projects when they've, in the past, cited forks as a deficiency of open source.

hexis• 15 years ago

Can anyone explain why Microsoft uses a "Promise" instead of a "License" as seems standard in the industry?

Niten3• 15 years ago

Someone probably did a focus group and found out people got 47% more warm-fuzzies from the word "promise".

me_again2• 15 years ago

Because they are not licensing a piece of software. They are promising not to sue if you implement your own compatible software. If it were software it would be licensed.

tzs2• 15 years ago

From what I've seen "covenant" is the most common term used for this kind of thing. For example, here's a page I put together once to help me understand the differences between the various patent promises that might affect ODF and OOXML, although half the links to the originals no longer work. It shows two Microsoft documents, a Sun documents, and the terms IBM uses for many standards side by side, with the text colored so that sections in the difference ones that correspond in function are colored the same. It makes it easy to look at one and see how the others word their similar section:

http://www.tzs.net/odfooxmlpatent.html

In essence, a "covenant" not to sue is a fancy way of saying "promise" not to sue.

As far as the difference between a covenant/promise and a license goes, the courts have been unclear in their guidance. Covenants/promises may not survive a sale of the patent--although the cases are mixed. Covenants/promises may not provide the person they are given to the right to sell things that use the patent to third parties (or rather, it may not apply to the third parties and so the patent owner might be able to sue them). The case law here is murky, too, with the latest tending to favor that the covenant/promise does apply downstream.

I've seen cites to at least one appeals court case where the court said all patent licenses are really just promises not to sue. That's because a patent does not give the patent owner permission to practice the patent. It just gives him the power to exclude others from doing so, and so he can't really license you the right to actually make something that is covered by that patent. All he can do is agree not to sue you if you do so.

Most of the cases, though, apply to covenants/promises to a specific party. E.g., company X and company Y are disagreeing over X's patent, and as part of some settlement X grants Y a promise not to sue.

Different considerations might apply when the covenant/promise/license is not to anyone specific but is rather a non-exclusive covenant/promise/license to everyone. When viewed as a license, this kind of license is something called a "bare license". Bare licenses are not good for the recipient, as they can be revoked at any time. What you really want is for the covenant/promise/grant to be viewed as a contract. Fortunately, there is a mechanism in contract law to allow this, called promissory estoppel. The basic idea is that if I make a promise to you (where you can be the whole world), reasonably knowing that you are going to rely on this promise, and you do rely on this promise and act accordingly, then the law will enforce the promise.

kenjackson• 15 years ago

Interesting.

So, what of soemthing like WebM? Does it have the same problems with respect to transfer of ownership?

profquail• 15 years ago

Since no one else has mentioned it:

http://pash.sourceforge.net/

There's been a (partial) port of PowerShell to Linux/Mono out there for a few years; maybe having the language spec will allow the project to go a bit further.

me_again2• 15 years ago

This is likely most useful for remote-controlling windows boxes from some non-windows endpoint. I can see that being handy for a unix-centric admin forced to admin exchange, for example.

leif• 15 years ago

Considering wrapping the perl interpreter to get a performant powershell implementation.

Extra lols from the "download spec page":

  > Supported Operating Systems:Windows 7;Windows Server 2008 R2
  > Microsoft Word or Word Viewer

PowerShell Specification licensed under the Community Promise

Related Stories