Getting Access to Products No Longer Available From Microsoft - legacy

As a consequence of a legal settlement with Sun regarding the Java technology, Microsoft has removed certain products from being available directly from them through any means. Here is an excerpt from their MSDN site:
http://msdn.microsoft.com/en-gb/subscriptions/aa948864.aspx
Products Unavailable due to
Java-related Settlement
Some products have been removed from
Subscriber Downloads due to the terms
of Java-related settlements Microsoft
made with Sun Microsystems. These
products are no longer available from
Microsoft in any form, but may be
available through third-party
resellers or Web sites.
This list includes large variety of products, including Office 200, Windows 98, Windows XP, Visual Studio 6.0, VSS 6.0d, and many more.
Microsoft suggests you can get these products from various "resellers" - but won't go further than that.
Does anyone know where developers can obtain access to these products (in our case for testing purposes) from inexpensive, reputable resellers? Or better yet, a legal and free resource to get access to the original media if you have an existing, legal license key?

What's the link for the page from which you pulled that excerpt?
I didn't do an exhaustive search, but Windows XP and VSS 6.0d are both available on my MSDN subsciber downloads page.
However, I don't see Windows 98 or Office 2000 listed.

Related

Publishing Word Add-In for use by customers

We are developing a Word Web Add-In that will be used exclusively by our customers rather than the general public. Customers will need to log into the Add-In in order to use it with credentials we supply. My question is, is this Add-In ok to be distributed via the Office Store? Will it fall foul of the validation process if its functionality is not publicly available ? Obviously, we can supply credentials to the verification team at Microsoft in order to get the app published.
If this is a problem, how do ISVs distribute Web Add-Ins to customers external to their organisation (i.e. Without Sharepoint or Office Admin Centre)?
This model is supported via the Office Store - this blog post on add-ins which target organizations and enterprises rather than consumers may be of interest to you.
Please ensure that your add-in description clearly states the need for an additional account, as well as supplying test credentials for the validation team to use.

Would the credits my app needs to function have to be purchased through the in-app purchase API?

I'm making a desktop app for a company, and they would like to get it featured in the windows app store for Windows 10 users.
The app will likely only work on desktop computers, it's not designed for mobile. What it does is perform lookups on lists of cell phone numbers, and outputs a spreadsheet with carrier info, and it requires a credit for each cell phone number looked up. The credits are bought in bulk through the company's sales team, there is no automated method to purchase them.
Because there is no automated system, it would be difficult to set up in-app purchases, also if Microsoft takes a cut of in-app payments then it wouldn't be feasible due to the tiny profit margin of the credits. But according to this (section 10.8.1), if the app consumes anything that has to be purchased then it needs to use the in-app purchasing api.
Does anyone know if there's some way around this? Or if it only applies to regular apps and not desktop only ones, which I understand are a different type of listing?
I realise I can get a developer account and go through this with them but I don't really want to spend this company's money on the dev account if Microsoft are just going to say no.
Thanks :)
That section of the policy refers to payments taken within the application.
It doesn't sound like what your application will do though. Your application is allowing the allocation (spending) of credits bought separately.
It's a small distinction but an important one. You may have seen other applications work around such limitations by requiring the user to go to a website to buy something and then return to the app to use it.
When submitting the app there is a declaration for "This app allows users to make purchases, but does not use the Windows Store commerce system." You can read more about this declaration at https://msdn.microsoft.com/en-us/library/windows/apps/mt148523.aspx but this shouldn't apply to your scenario.
There are potential legal implications here and if the company has any concerns about entering a legal agreement with Microsoft regarding financial matters then they should seek appropriate legal council. Having a developer ask other developers about legal matters is likely only suggest asking a lawyer.

HTML5 offline authentication security issues

I'm doing a mobile WebApp using HTML5. My problem is that the "post-login" pages cached by the HTML5 application cache, from what i understand, remain still unsafe. Is there a solution? What is the best way to ensure an offline authentication hiding user/pass and "post-login" pages from intruders?
I am just starting to delve into HTML5 usage of local storage via the Manifest option (http://diveintohtml5.info/offline.html) and this too is a concern for me as much for privacy as security. Two things came to mind: Ezncrypt and the Editor's Draft on Web Storage (Privacy and Security), links to both below...
While I do not know if this will be the 'best' answer, figured anything would be better than nothing and after all you posted this question back on Feb 2, 2012 and no one else has offered anything.
Caveats (ezNcrypt):
It works on Linux
Its a Commercial product with a 30 day trial, honestly do not know the cost as I am not affiliated with them, just heard of what they do via a local meetup, LAPHP, LAMySQL or LAWebspeed last year, and it sounded interesting enough to note for future reference. Transparent encryption will be huge.
Google Ezncrypt products to get a link, I am limited to two here.
Even if its not the 'right' solution for you or others, perhaps it will point you in a good direction with some decent search terms to find more.
If the encryption is handled "transparently" below the application / data layers, it will just work regardless of the IT knowledge of the user.
If you are willing to share some contact information with them, you get this PDF file with 4 case studies, FTP, NoSQL, SQL and something else... its free.
http://blog.gazzang.com/white-paper-unifying-data-encryption-liberating-transparent-encryption-for-any-purpose-/?utm_campaign=Whitepaper&utm_source=Whitepaper
I should get a commission, lol. Hey if it helps us find a solution, that is all that matters.
Whatever your decision make sure you go through the Editor's Draft, Privacy and Security to dot your i's and cross your T's, especially sections 6 Privacy and 7 Security.
http://dev.w3.org/html5/webstorage/#the-localstorage-attribute
Just thought of another, I did not look except to provide a URL to their checklists (cheat sheets) , but my guess is OWASP would have one or two checklists that might lead you to something. Just think of your device as a little desktop/server and see if any of those apply. To bad my Nokia N800 broke on me, a full blown Linux computer in my hand circa 2006 and the new Linux handhelds circa 2012 are so much more powerful. Just use a Linux distro with a small footprint on a device with exchangeable storage (Micro SSD Cards would work...the Nokia N800 had two slots in 2006) and there is no limit to what you could store locally and run offline. Here is the URL to the OWASP checklists:
Sorry limited to two links, google OWASP cheet sheets and you will find them.
If a handheld is truly 'smart' you will have root (administrator) access to the device and underlying operating system / file system. Every operating system has methods to encrypt data on the fly, but you have to have access to utilize them. A device that does not give you this access (usually for proprietary reasons, most often to force you to buy a new device in 6 mos to 1 year) is limiting your options artificially for the wrong reasons and is simply not smart. Remember that all versions of Android (Linux) are not open and rootable, so do your homework or you will end up with an expensive paper weight in the near future.
I would recommend only buying smart handhelds that allow for root/admin access.

Creating software derivative works from open source [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
This question has always been around my head.
Can someone create a new product based on an existing open source project?
Say you want to create an "Apaxe webserver" that is basically Apache with your some extra plugins ( say support for ASP or something similar )
Is this possible?
Would you be able to create a closed source product ( either free or licensed )
As for GPL seems clear it is not possible because the source should be open. But what about Apache license, BSD and others "corporate friendly"
Are the price ( free for most of the project ) , bug fixes and counting with the core development team the only thing that prevent from others to commercialize those OS products?
What about: Khrome a commercial product based on Chrome with ActiveX support ( who would dare to do such a thing :P )
EDIT
Thank you all you all for your answers.
So, again
What prevents from similar ( clone ) products from appearing in the market?
:)
NOTE: I know we are not lawyers, and we could read every OSS license here http://www.opensource.org/licenses.
Nothing prevents clone products appearing on the market. Look at all the various linux distributions, for example. The X.org project was forked from XFree86. And so on.
It happens relatively infrequently, though, for a couple of reasons:
The original project has the first-to-market advantage
The original is usually being given away free
So unless your version is significantly better than the original, you're not going to get much uptake or make much money out of it. If your version is significantly better, then go ahead!
From the original developer's point of view, the power of the GPL is that it forces such clones to share any improvements with the rest of the world, so they can be incorporated back into the original.
Generally, my read of the licenses is:
You can make a derivative work of any project based on one of the popular licenses (i.e. GPL, LGPL, Apache, MIT, BSD).
You may charge money for at least the distribution & packaging of your derivative work.
Depending on the license, you may also have to distribute your modifications in source form and/or include notices in your distribution.
So to your question about Apaxe: yes, you can do this as far as I know. I believe that the Oracle HTTPD server is actually derived from Apache, and it's definitely not free!
Here's my 10,000 foot view of open source licenses:
"Real" open source licenses (eg: MIT, BSD, Apache I think, etc.):
You can do whatever you want with licensing derived works. It can be closed, open, etc. The license places no restrictions on your licensing of derived works.
"Restricted" open source licenses (eg: GPL, LGPL):
Derived works must include specific license restrictions; for example, the GPL requires derived works to be GPL-ed. Essentially your rights are restricted for derived works.
Charging for products is separate from either of these; neither type restricts charging for products, although some licenses place restrictions on the rights you can retain and/or must convey to receivers of your software (ie: the "Restricted" licenses).
Hope this helps.
Edit: Changed by original "DRM" term for GPL type licenses to "Restricted", cause some people attach negative connotations to DRM, and/or cannot grasp how the GPL restricts your rights for derived works in an almost identical way to any other type of DRM (ie: controlling what you can do with it). Seriously, you can be a FSF supporter and still grok the concept that the GPL is more restrictive than "real" open source licenses. The question is not about which type is right or wrong, it's about what the difference is.
Red Hat (and most of the other Linux vendors) charge for support, not for their software - which is primarily how companies can make money off of code that is GPL licensed.
It really depends on the license the open source project uses.
Disclaimer: I am not a lawyer; you should always read the license for full details.
If a project is under the GPL, then anything you derive from it must also be released under the GPL (or a compatible license, and if it is released at all). You're still allowed to charge money for it, but anyone who buys it has to be provided with the full source, and you can't prevent them also selling it, or giving it away for free.
If a project is under the BSD license, you can do pretty much anything with it including incorporate it into a proprietary closed source product. There is BSD code inside Windows!
Other licenses fall somewhere in between.
look at MyEclipse, its really just eclipse+free plugins+myeclipse's plugins and it cost some money.
What prevents from similar ( clone ) products from appearing in the market?
Nothing. The real question is: How can a similar cloned product get more popular than the original product?
Some cases where somebody might clone/fork a project:
Picking up a dead open source project and continuing its development. If the new derived product is maintained regularly and it gets more updates than the original version, then people will start using the new version. This is one of the big benefits of open source - good software does not need to die, just because the original developers stop developing it, but someone else can continue from where they were left. One example of such a project (which I've used) is that the development of Turck MMCache had died out in 2003, so eAccelerator forked it and continued its development in 2004. I'm sure there are lots of other examples.
There is a disagreement in the developer community of an open source project, and the project splits into two. That's why it's best to strive for a common understanding in open source projects, so that the community would not be split needlessly. If a project is split, the projects may continue living if they managed to attract enough developers and users, but otherwise they may slowly die. In general, splitting should be avoided, because it makes the community more fragmented and weaker. IIRC, in the video presentations of Producing Open Source Software (good stuff!) they mentioned a case where the original developer of some project wanted to take a completely new direction in the development, but the community of other developers wanted to keep the old direction. The result was that the original developer was kicked out of the project, so he created a fork of the project, while the rest of the community continued the development of the original project.
A commercial closed source derivative of an open source project which was released under a permissive license (for example BSD). The derived product would need to be considerably better in features or in support than the original product. Otherwise people will prefer using the original open and free product.
Isn't that essentially what red hat does? Even though they have fedora, they are charging money for their linux distribution. Granted, they've written a lot of code for it, it's still based on open source-stuff.

OpenSource: Collaborative Design

After delving into the world of opensource I have found implementation is emphasised over design. Version control allows for a project to branch off in many directions, which projects may do; this suggests lack of consensus or direction amongst the participants.
What software or websites are useful for collaborative design?
There are literally hundreds more collaboration apps out there and more keep appearing by the day, but these should get you started:
Source Control (Online):
Assembla - Public source is
free, private repositories are paid
Source Forge - Open source only
Google Code - Open source only
Git Hub - Public source is free,
private repositories are paid
Bug Tracking/Project Management
LightHouse - Unlimited open source, paid private projects
FogBugz - Full version is free for up to two developers
BaseCamp - Paid only
Trac - Not hosted (although Assembla hosts it), open source - Python
Bugzilla - Not hosted, open source - Python
Mantis - Not hosted, open source - PHP
Mind Mapping
MindMeister - Free for small
plans, with options to upgrade
Documents
Google Docs - Free
Buzzword - By Adobe - free
Scribd - Free
Graphics
Aviary - I'm not quite sure how
collaborative they are, but I think
you can use their tools that way
Photoshop Express - Another
Adobe product
Picnik - Free
Whiteboards
Scriblink - Free with paid
options
skrbl - Free for public, paid
for private
Dabbleboard - Free and paid
plans
Hosted Wikis
pbwiki - Paid plans
Wikidot - Free with paid plans
Miscellaneous
Acrobat - Part of Adobe's
online suite
Zoho - Fits into a lot of
categories
I've been studying collaborative design early in my Ph.D. (contact me if you want a literature survey draft that I wrote about it a back in 2003).
Anyway, collaborative design applications (as in UML modelers) fall into three categories in terms of timing:
Synchronous - Two people or more editing at same time
Asynchronous - Check-in check-out model, a mess if multiple people edit at the same time.
Hybrid (can share certain things in real time).
In addition, they fall into three categories in terms of metaphores:
- Desktop based - Essentially something like rationale rose with multiple user support
- Whiteboard based - Free canvas, not necessarily structured, sometimes has support for UML recognition. Usually a mess to manage multiple models.
- Hybrids
So this gives you a 3x3 "design space" of tools, and there are research tools inside every one of them.
The problem is that in switching to collaborative work there are many usability issues that are difficult to address. For example, access control, synchronization, awareness, shared viewports, etc. There are some academic advances on these, but they're not necessarily in tools yet.
If this is the topic you're interested in, comment, and I'll post some of the tools I'm familiar with.
I would suggest using a Wiki to document/explore the design.
A mailing list. And opensource projects argue on enough of them. I doubt lack of collaborative tools is where the lack of design emphasis comes from.
In no particular order:
A good email client (I use gmail)
Good wiki software (I use media wiki)
Github or an evolved source repository that allows for easy branching and comments on check ins
A chat room, plain old irc or that built in messenger one
A news group or mailing list (I use the free google one)
Skype
I am somewhat skeptical about collaborative design. From Scobleizer: Why Facebook has never listened and why it definitely won’t start now:
My former boss, Jim Fawcette, used to
say that if you asked a group of
Porsche owners what they wanted they’d
tell you things like “smoother ride,
more trunk space, more leg room, etc.”
He’d then say “well, they just
designed a Volvo.”
also from the comment:
Apple never listens to its customers.
In fact, it prides itself on not
listening. If you listen to your
customers, you will never innovate and
you will never be ahead of the curve.
You will always tweak and fix minor
things on what is top of customer mind
that day, week or month.
I agree with the wiki answer. I'd suggest looking at MindTouch. Our company uses them for our Intranet and for other internal and external project collaboration/management.
A wiki (such as ScrewTurn, or MediaWiki) is a good tool to document a project.
BaseCamp by 37 Signals
Microsoft Office Live Meeting
For us, all we use is Adobe Version Cue, Google Docs, Google Calendar and Gmail.
Design wise, Version Cue does the trick in terms of file management really well.
As for Google, well, it helps organizing all of my activities more than very well. I find most collaboration tools, like Basecamp, a tad too restrictive or just not exactly right. Google lets me organize my stuff just the way I want it to be.
For collaborative design ... without a doubt, it's
http://conceptshare.com