[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] New Update Manager UI : Your thoughts

Title: Re: [equinox-dev] New Update Manager UI : Your thoughts
OK, lets step back and look at it differently.

I don’t think this would be illegal, but I am not a lawyer, and I don’t play one on TV.

Infor (the company writing the software) is using equinox server-side to assemble an ERP system at WidgetCo, the company that manufactures widgets.

This is not an eclipse IDE of any kind.

WidgetCo and Infor have a licensing agreement between them. WidgetCo has purchased a license for Infor’s software and can receive free updates for 1 year from the purchase date. Now, instead of automatically accepting license agreements, we have a more complex requirement, but a real one that needs a solution.

Possible options:

1. There are update sites that are always trusted by the update manager. The user that sets the “I trust this update site” flag must have in essence agreed to the license in advance. Such as free updates for a year as per a license agreement. In this case, Infor will stop populating the WidgetCo update site with new versions after a certain date, and the onus is on Infor to make this happen. Probably by getting a new license agreement signed. Very little needs to be done in the update manager in this case, except to trust sites that are marked as trusted. Notes could be added as to why it is trusted, perhaps.

2. The update sites in the update manager could have attached multiple license keys. These keys are transmitted to the update site with the update request. Now the update site is not a simple set of web pages and resources served by a apache. It needs to be a web application that can validate the license keys. The update site either sends the updates or rejects the request.

3. The update site provided by Infor could be behind a password protected URL. Access to this URL is only given to customers that have a signed license agreement. The license requirements are all handled outside of the scope of the update manager. The the update manager, the update site is marked as trusted.

4. Infor provides a password protected URL from which WidgetCo can download an update site that WidgetCo can host locally. Again, Infor and WidgetCo have the license agreement managed outside of the scope of the update manager. This downloaded and hosted update site is marked as trusted.

In all cases, the marking of an update site as trusted means that all license management is being handled outside of the update manager. And the act of marking an update site as trusted means that the administrator has agreed that all licenses required at that site are already handled outside of update manager.

An update site should have the ability to override this and say: “Never allow update manager to trust me”. This could even be the default.

Without introducing a full blown license management system, we cannot get too complex in the requirements here. But server-side implementations will require the ability to trust some update sites and not need license agreements individually agreed to. If only because sometimes there will be no human and no UI present when the update happens.

-Don


Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx

On 6/13/07 11:56 AM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx> wrote:

I think there are legal ramifications, at least in the United States for that.  While we’re all annoyed by licenses, I don’t think you can “auto-dismiss them” any more than you can stamp your car loan with your signature.

-Brett

On 6/13/07 8:59 AM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:


True, but it can also be a policy of a plugin consumer to accept the licenses of trusted update sites. Then the consumer only has to determine which update sites will always be trusted.

In using equinox on the server side, the update sites will usually be in the same company.

-Don

Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx

On 6/13/07 9:55 AM, "Peter Manahan" <manahan@xxxxxxxxxx> wrote:


The need for license acceptance is  typically a requirement discretion of the plugin provider and not the consumer of the plugins. So allowing the consumer to disable the license acceptance should only be optional at the discretion of the plugin provider.

Peter

equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 09:04:39 AM:

>
> The provisioning system should already know about the sites and
> should be able to discover more.
>
> Actually I missed in there where the users said which plugin they wanted.
>
> User should not have to accept a license if the plugin is coming
> from a known/trusted site.  Sites should be ranked in this way
>
> Restart may not be needed
>
> Jeff
>
>

>
> "Prashant Deva" <prashant.deva@xxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 06/12/2007 08:26 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

>
> To

>
> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
>
> cc

>
> Subject

>
> Re: [equinox-dev] New Update Manager UI : Your thoughts

>
>
>
>
> Ok, here is some thoughts on the gui for installing a new plugin.
> This is in keeping with the philosophy of keeping the simple things simple.
> I wish there were a place where I could upload some docs and sample
> images to make the point more clear, but i will just type some stufffor now.
>
> 1.        User clicks on 'Install new plugin' button
> 2.        Dialog box with single text field asks to enter the url of
> pluign update site.
> 3.        update manager automatically gets the latest available
> version of the plugin.
> 4.        asks the user to accept the license.
> 5.        if license accepted, then installs plugin and asks user torestart.
>
> The update site url, etc are automatically saved by the program and
> user doesnt need to give a 'name' along with the url as we have to do now.
> Also no dialog box for confirming 'install all'. All user has to
> enter is the url and accept the license.
>
> the dialog in step 2 can have an 'advanced' button, which when
> selected allows user to choose the exact version to install.
>
> your thoughts? any compulsory steps in the install process we might
> be missing this way?
>
> prashant_______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev




_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev